cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [cforms] Widget states in request-scoped forms
Date Wed, 16 Mar 2005 07:10:57 GMT
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.
> 
>> 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

> 
>> 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.


-- 
Reinhard Pötz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message