Hello Frederic,
In progress, but haven't finished yet. Today I'm planning integrate
javascript stuff with backend. Let you know and I'll try to do it ASAP.
Siarhei
On 9/4/07, frederic <[EMAIL PROTECTED]> wrote:
>
>
> Hi Siarhei,
> Any news from your data binding mechanism implementation
> (qx.io.databinding.*) ?
> My current qooxdoo's application has a very bad implementation of form
> handling and I would be very happy to test your "form emulation" described
>
> in the PDF doc.
>
> Cheers.
> Frederic
>
>
>
>
> bibliograph wrote:
> >
> > Hi Carsten,
> >
> > I just saw the answers to Siarhei's post right now ...
> >
> > Carsten Harnisch schrieb:
> >> Siarhei!
> >> We had started to work with QxTransformer and picked the
> >> "DataProvider"-stuff here as a starter for our own implementation. I
> just
> >> summarize a few issues that we encountered here. Please feel free to
> >> adapt
> >> these issue to your concept :
> >>
> >> 1) Internal Transport-Format
> >> The usage of "sub-arrays" for the data-transport is not very handy. The
> >> current " MDataManager.js" will (JSON-)serialize the data in structures
> >> like
> >> obj.TextFieldName.value = 'data;
> >>
> >> as for ComboBoxes this will be :
> >> obj.ComboBoxFieldName.value = 'data;
> >> obj.ComboBoxFieldName.selected.value = 'data;
> >>
> >> than for Checkboxes:
> >> obj.CheckBoxFieldName.checked = true/false;
> >>
> >> As for writing a backend ( e.g. a database storage) this is not very
> >> handy,
> >> as you have to know how get/set the data depending on the clientside
> used
> >> widget. So we remodeled this part to always return a "flat" value, so
> the
> >> clientside widget is responsible how to "bind" the value to its
> internal
> >> "values".
> >>
> >> So we have only :
> >>
> >> obj.TextFieldName = 'data'; // uses setValue
> >> obj.ComboBoxFieldName = 123; // selects the ListItem with the value 123
> >> obj.CheckBoxFieldName = 1; // transforms to setChecked(true);
> >>
> >> This is much easier on the backside as a "SQL-resultset" could be
> mapped
> >> back and force.
> >>
> > As I wrote in my last email, you certainly have a point here - it is not
> > a good idea to have the property names widget-specific. However, I would
> > not use completely flat values since even though it simplifies things
> > quite a bit, you loose the ability to set several properties at once for
> > more complex widgets - for example, widgets can be checked and enabled,
> > have text and a validation regex, and so on and so on, stuff that could
> > change dynamically. I like the idea to be able to keep this flexibility.
> >
> > Christian
> >
> >> 2) Error Handling
> >> Normally a backend would not only store the data but also add some
> >> validation logic. So we changed the return format of the backend to
> give
> >> the
> >> ability to return "validation-message" back to the client. This regards
> >> simply return "error-message" that are routed back to the widget. So
> the
> >> widget gets an event (implemented with a MixIn) with the validation
> >> error.
> >> The widget then might do an action e.g. changing the background-color,
> >> showing an alert, popup a tooltip, or delegate the error to another
> >> widget.
> >> (Here we have a .NET inspired ValidationError-Widget).
> >>
> >> 3) Formbased Validation Errors
> >> In conjunction to 2) we have also situation where the validation has to
>
> >> be
> >> done on a form-based level. E.g. a "Change Password"-UseCase would need
> >> to
> >> check if 2 password fields ("repeat password") have the same values.
> Here
> >> a
> >> validation-feedback might need to postback the validation to 2
> >> client-side
> >> widgets. Our implementation will return also a "Script"-Field that
> could
> >> be
> >> eval'ed and does the feedback to the user, e.g. :
> >>
> >> (done on the serverside)
> >> result.script = '
> >> this.pwd1.setColor('red');
> >> this.pwd2.setColor ('red');
> >> alert('The passwords have to match');
> >> ';
> >>
> >> ----
> >> The clientside then just does an eval(result.script);
> >>
> >>
> >> greetings
> >>
> >> Carsten Harnisch
> >> -----------------------------------
> >> InTradeSys Limited
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] Im Auftrag von
> >> Siarhei
> >> Barysiuk
> >> Gesendet: Mittwoch, 25. Juli 2007 19:46
> >> An: qooxdoo Development
> >> Cc: Christian Boulanger
> >> Betreff: [qooxdoo-devel] Data Binding Mechanism. Qooxdoo and
> >> QxTransformer.
> >>
> >> 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
> >>
> >
> >
> >
> -------------------------------------------------------------------------
> > 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
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Data-Binding-Mechanism.-Qooxdoo-and-QxTransformer.-tf4149546.html#a12474475
> Sent from the qooxdoo-devel mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
