cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [cforms] Widget states in request-scoped forms
Date Wed, 16 Mar 2005 22:28:16 GMT
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


Mime
View raw message