Hello Martin,
thank you for the feedback.
Martin Wittemann wrote:
>
> I took a look at your code especially the table controller code and
> the first question came to my mind is why do you need a store in the
> controller. Thats a connection we tried to omit at all cost because we
> could that way use both parts – the controllers and the stores –
> separate.
>
When I wrote the code for this, I thought that this will raise concerns
since it departs from the pattern you have established in the other
controllers. It is not that I want the store to be there, just that I did
not know how to solve it differently. The problem is that I do the
synchronization of all the tables that are connected to the store through
their controller by dispatching events (see below) and that I cannot "bind"
events the way I can bind properties. Instead, I propagate the events to the
store and add listeners that monitor the store's events. In order to do
this, though, I need a reference to the store. Maybe this can be done
differently - I am grateful for any idea you might have.
Martin Wittemann wrote:
>
> And why does the store fire change and changeBubble events? Should not
> the model be updated and therefore the model throw those events?
> As you sure can see, i did not dig in too deep into your code. Still
> too impressed by the demo application. ;)
>
Those events come are forwarded from Table or TreeVirtual widgets which are
either in the same application or are in a different window and are
connected through the server which forwards their events to all other
stores. Maybe a graph helps to understand:
Tree1 <==> Tree1 controller <=\
/==> Tree4 Controller <==> Tree 4
Tree2 <==> Tree2 controller <==> JsonRpc Store1 <==> Server <==> JsonRpc
Store 2 <==> Tree5 Controller <==> Tree 5
Tree3 <==> Tree2 controller <=/
\==> Tree6 Controller <==> Tree 6
Tree 1-3 and their controller, plus the JsonRpc Store 1 are in one window,
Tree 4-6, controllers and JsonRpc store 2 in a different one.
If Tree 1 dispatches a "change" or "changeBubble" event, the Tree1
controller forwards it to the store 1, which forwards it to the controller
of Tree 2-3, which, in turn, update the controlled tree widgets. In
addition, the store puts the events into a queue which is sent to the
server. With PHP, I cannot use a cometd-like solution, so I poll the server
periodically, dump the new events to it, and receive the events of the other
connected store (which is connected to Tree 4-6), which are then dispatched
to Tree 1-3. Store 2 picks up the events from the server and dispatches them
to Controllers 4-6. This way, at least in theory ;-) all the trees should be
synchronized. The server would be in charge of making sure no
inconsistencies occur when several stores update the same tree node at the
same time.
Martin Wittemann wrote:
>
> I have one last general question. How did you manage that the changes
> in the table e.g. in a checkbox appear in all other tables at well?
>
What I said above for the TreeVirtual applies for the Table as well.
Internally, they are very different, because the tree data model is much
more complicated than the table data model. Also, the Table has its own
mechanism to pull data from the server, which has to be implemented for the
TreeVirtual on a custom basis.
Hope this answers some of your questions. Please let me know any other
questions and suggestions how to better adapt the existing code to the
qooxdoo databinding architecture.
Christian
--
View this message in context:
http://www.nabble.com/Databinding-for-qx.ui.table.Table-and-qx.ui.treevirtual.TreeVirtual---first-alpha-version-tp23622558p23631645.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
