Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Hi all,
I broke car selector sample :-)
Problem is that when you assign / bind initial values to the form, <on-value-change/> events are not fired, and form ends up in the inconsistent state. Quick hack I used to fix this was to make Form.fireWidgetEvents method public and call it directly from the flow/action to make sure that all is ok; but this is clearly a hack and I'd like to hear "expert opinion" on the subject.
The solution is to tie the loading phase to the global form processing. I started this by adding load() and save() to the Form class, but left them commented out waiting for some more thoughts in this area, since the binding is strongly separated from the Form object.
Now your use case clearly shows that making the binding an integral part of the form processing is useful.
So let's officially introduce Form.load() and Form.save() and make them the preferred way to use the binding framework.
Sylvain, care to explain a bit more?
I do remember a more conceptual agreement on binding being a natural part of the form's being (although the original late arrival of binding in woody kept it modestly separate) and I thought we said back then that save and load on a form were logical extensions...
So I'm quite +1, I'm just not fully aware of what it is about yet...
Sylvain
thx and regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
