Hi Frederic & all,
Siarhei is working hard on getting things done. In a different issue, I
was talking to Andreas about the qooxdoo-contrib project and I wonder if
the whole databinding stuff should maybe put there under a different
namespace rather than "qx.io.databinding". We are currently putting it
in the custom source folder of qxtransformer, but we should also make it
available for people who want to use javascript and not xml.
Christian
frederic schrieb:
> 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
>>
>>
>>
>
>
-------------------------------------------------------------------------
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
