Cleancodefactory / BindKraft

An OOP Javascript platform/framework with data binding, in-page windows and vast API aimed at WEB development that treats WEB pages as desktops running multiple apps simultaneously.

Home Page:http://bindkraft.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hierarchy linkage signaling

michaelelfial opened this issue · comments

As the hierarchy of the UI and code structure is used for communication (StructuralQueries) we need signaling that enables the elements in the hierarchy to take actions when the hierarchy changes / links together (at least).

For those not familiar with this - the structural queries go from a "place" in the hierarchy down to the root and are stopped at certain points. This allows a component / code that belongs to something that is part of the hierarchy to request actions from some, unknown for them, logical parent. This could be parent window or the app for example. The main benefit of this is that the existing hierarchy is obviously created in a way needed by the application for logical reasons and thus naturally establishes parent - child relations between its parts. This allows many features to function without the need for excessive configuration that plagues many frameworks and libraries using abstractions like services, workers etc. Piggy backing this communication mechanism we simplify drastically service location, element collection (similar to service location, but rather in reverse - way to find one or many
partners that have to be notified for something or asked to do something) and many other features. This works well, but without a "self-diagnostic" mechanism the hierarchy cannot inform its participants when it is available and if it is complete (for instance). As a result of this programmers have to be careful how the construct the hierarchy and make sure they do it from the root and not in pieces. These requirements can be cumbersome to fulfill and a way to limit them or preferably fully eliminate them will be something very nice to have.

Illustration of the problem can be something as simple as using readdata attached to an event fired by some service implemented in a remote parent or the app for instance. It wont be able to work until the template in which it is used is somehow linked to the service provider. This can mean the window in which the binding is to have a parent window, its parent to have a parent and ultimately be attached to the app. Currently to make sure this will work you have to explicitly invoke update (updateTargets on the window or the view where such needs exist) after completing the entire construction of the UI. With signaling supported by the participants of the hierarchy it will be possible to automatically invoke such a binding (or any component with similar needs) to try to link to its service provider when the hierarchy detects that it was fully constructed (linked).

I am assigning a bug label to this, because the effect will eliminate many unexpected problems (albeit easily solvable) met by people who are new to BindKraft.