cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Revisiting Woody's form definition
Date Wed, 30 Jul 2003 14:19:23 GMT
Carsten Ziegeler wrote:

>Marc Portier wrote
>
>  
>
>>>I think this has to be changed :) It should be done dynamically when
>>>the form is "rendered".
>>>
>>>      
>>>
>>this is fundamentally different to how it is done now
>>
>>we seem to think there is some advantage for 'caching' the 
>>form-definition and instantiating the form from there
>>
>>even worse: the flow examples to date are holding a reference to 
>>the form instance (just to give a popular usage example)
>>
>>as is now (and redeamed useful) the form has an important 
>>function in analyzing the request-parameters and triggering the 
>>validation.... all of those are happening before even deciding 
>>which business object should be retrieved or if the form needs to 
>>be rendered again or not...
>>
>>to support the general case woody kind of takes the existance of 
>>it's form-definition prior to the existence of any business 
>>object model (because it should be useable without it?)
>>
>>    
>>
>Hmm, ok, caching does not prevent to have some dynamic elements
>in it. You can cache, let's say 89%, and 11% are calculated dynamically.
>
>A question I was always asking myself is: how does woody handle
>user dependent forms? Which means, if the same form is used inside
>a user session and for example the user can edit his personal
>information. So you have a Form object for each user but use
>of course the same form description. Is this possible? (I guess
>so, but just want to make sure).
>

Carsten, I think you need to know a bit of the internals of Woody. For a 
single element of the form definition file, say <wd:field>, 3 classes 
are involved in its processing :
- FieldDefinitionBuilder : analyzes the <wd:field> element and from its 
attributes and content creates a FieldDefinition
- FieldDefinition : holds the characteristics of a <wd:field>. It is 
cached, and only one instance of it exists in the system no matter how 
often the form definition is used.
- Field : holds the data for a particular use of the field definition. 
It's what is referred to as "instance".

So, when a form definition is used for the first time, it is parsed by 
implementations of WidgetBuilder (FieldDefinitionBuilder is such an 
implementation) that produce a tree (some widgets such as Form or 
Repeater have child widgets) of WidgetDefinition objects 
(FieldDefinition implements this interface). This tree is cached.

When a form instance is created, the WidgetDefinition tree is crawled to 
produce a Widget tree (Field is an implementation of Widget). These 
objects are responsible for formating/parsing the values. These are very 
lightweight objects that delegate most of their processing to their 
WidgetDefinition.

Hope this makes things clearer.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message