IMHO, this might be a mistake. I sometimes got the impression that we spend a lot of time to independently evolve things that are quite close to what XForms allready does. And the last time I reviewed the spec it seemed to me that the XForms event model would work well at the server side also.
Hm... not sure about that.
I shamely admit I haven't read the final version of the XForm spec :-/
Same here ...those days the reaction on the w3c XForms list was "why on server - this is for the client" and our interest was not shared. ...maybe this has changed now. Need to have a look again anyway.
Another thing is having a request processor that writes into the widget tree instead of letting the widgets read from the request. This makes it possible to plug in an XML based request processor instead of the request parameters based, e.g.
The danger here is to fall again in the XMLForm trap, where all request parameters where checked to see if they corresponded to some valid XPath expression.
Exactly! For a secure system we need to keep the indirect population approach. Although I had some continuation related RT on this...
What actually is suspected to be populated on the next request is available through the result of the last continuation! Given this technique an automated and still secure population mechanism could be put in place.
...but since I not yet got into the CForms codebase I am not sure how CForms could benefit from this idea.
cheers -- Torsten
