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
