Hello Siarhei,
thank you for your work! I think it's a good basis to start - what needs
to be elaborated in your documentation is the kind of response expected
from the server - since the backends need to provide the necessary data.
What I did in my first attempt at databinding is to require the backend
to return a json structure that specified the type of property to which
the returned data should be set - i.e.
{ value : "my text" } for a textfield and
{ label : "my label" } for an atom
this has the obvious disadvantage of being widget specific, but the
advantage to be able to set several properties at once. There should be
some kind of normalization of property names that are usually set.
I then had added more complex stuff, such as
{ list : [ { value : 1, label : "first listitem" }, { value : 2, label :
"second listitem" } } }
{ treedatamodel : [ { parentNodeId : 1, label : "my label" , ....} ] } and
{ tabledatamodel : [ [ "foo", "bar", ... ] ] }
how have you envisioned the API for updating the client or the server?
in my current implementation, the commands are
mywidget.updateClient(params)
mywidget.updateServer(params)
The parameters can either contain additional data sent to the server
(since the widget data is automatically sent) or change the remote
procedure the data is being sent to (or queried from).
Christian
P.S. I just emerge from organizing a conference with more than 2000
people and 50 staff - I used a hastily written qooxdoo-based app to do
the staff scheduling and it was extremely useful!! Now it is back to
qooxdoo-coding for relaxation!!
Siarhei Barysiuk schrieb:
> Hello folks!
>
> For few last day I was thinking about data binding functionality for
> qooxdoo (including 'plain html forms'
> emulation and auto completion) and I would like to present results of
> my work for discussion.
> I will be really appreciated for any remarks and suggestions from all
> developers. If you have any questions
> fell free to ask. Hope it will be interesting for you.
>
> I would like to notice that this is only concept. I've already
> implemented few parts but not everything.
> I'm working at this task at present. This is last part of work before
> initial release of QxTransformer.
> (In document I didn't pay attention to backend because you can
> implement backend in different ways.
> Would like to concentrate only on JavaScript qooxdoo API and
> QxTransformer syntax.)
>
> The concept is based on functionality which we have now in
> QxTransformer (written by Christian Boulanger)
> with improvements (which make API more flexible).
>
> Please find attached Data Binding Mechanism Concept document.
>
> Thanks for any remarks and suggestions.
>
> Best regards,
> Siarhei Barysiuk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
