Marc Portier wrote
this is fundamentally different to how it is done nowI think this has to be changed :) It should be done dynamically when the form is "rendered".
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
