Hi Jim,
Jim Hunter wrote: > > Very nice demo, as always! I have not been following the data binding > threads much so please forgive me now if my questions are obvious. You > mention that data stores can be bound to other data stores, I am going to > infer that this means if one data store changes (say via selecting a new > row > in a table) that it can trigger another data store to update and then any > bound controls of that data store would then update? I hope this makes > sense. What I have lots of in my application, are tables that the data in > them is dependent on the selected row of another table. What I do right > now > is when the selection changes on any table (because I do not know > relationships at design time) I have to send a command to the server to > re-fetch all queries and then send a bunch of code back to re-populate the > tables. Being able to set this up to happen on it's own would be > outstanding! I am trying to get a few pieces of my current project to QA, > but when I am finished I think I will dive head first into data binding to > see how much easier my life is going to get with it. > A behavior like the one you decribe has been the focus of the current databinding implementation in qooxdoo with the bind() method. There was an email by Martin with a slide show that explains that in detail. So far, however, I haven't integrated this yet, but will do this shortly - it should not be too hard to do. It has to go something like this: We need: 1) A table/tree source widget where the user can select something, and its controller. 2) A marshaler with a property storing the method name for retrieving the data from the jsonrpc backend and a property that stores the value(s) to pass to the method. A change of this property will trigger the rpc request. 3) The jsonrpc store that is initialized with the service name and this marshaler. 4) The target tree/table widget, and its controller, bound to the jsonrpc store. Now we nee to bind a property of the source widget which contains the values of the currently selected row to the marshaler property which triggers the request, which will then trigger an update of the target. Or we put this property at the controller level, so that only the controllers talk to each other: source-widget <==> source-controller <==> target-controller <==> target store <==> target widget so that the business logic does not need to know what store is involved. that is probably a better idea. Martin, do you have suggestions? -- View this message in context: http://www.nabble.com/Databinding-for-qx.ui.table.Table-and-qx.ui.treevirtual.TreeVirtual---first-alpha-version-tp23622558p23624973.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
