Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Another idea I had is, that I could work on making the form object serializable and save the state in a hidden form field. The price to pay would be increased network traffic but the advantage of a stateless presentation layer wouldn't get lost. Hmmm the more I think about it the more I like this idea .... wdot?
You should have a look at the XMLAdapter class in o.a.c.form.util. It does handles form serialization/deserialization in XML. AFAIK it doesn't keep state, but this could easily be added.
Thanks for the pointer! This should be very helpful, if I go this way.
Is there anything else that is necessary to _completly_ describe the state of a form, except the value and the "visibility state"? (events, validation errors, ...?)
Events are inherently transient (i.e. they are produced and consumed as part of the processing of a request). Validation errors are part of the global state of a form, as non-active widgets will loose their value and any validation as they don't read their value on the request.
You also have to include <fd:repeater-size> in your form template so that the size of repeaters is transmitted back and forth as a hidden input.
ok, so we need following information to describe the state of a form:
1. widget value 2. widget visibility state 3. validation errors 4. repeater size
Yes, that should be ok.
Thinking further, the use of <ft:repeater-size> isn't needed as this information will be part of the serialized state.
This means that I would have to enhance XMLAdapter to save this information too. Then I would extend the FormsTransformer to add a hidden input field that contains the compressed and encrypted XML.
Encrypted? Beware of security through obscurity, which is not a good solution, especially when the encryption/decryption code is opensource ;-)
yes, but if the encryption key is customizeable (e.g. in cocoon.xconf) this shouldn't be a problem
Ah, ok. That makes sense.
When the request comes back to the server, the controller checks for the hidden field and deserializes it.
By 'controller', do you mean FormSubmitAction?
for example, yes.
It would be cool to have a ready-to-run action in Cocoon for those situations where you cannot use flowscript.
Maybe this could be implemented as a new <ft:serialized-state/> template instruction.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
