cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Selectors for Woody FormManager and BindingManager
Date Mon, 22 Dec 2003 11:07:26 GMT

Hugo Burm wrote:

>>From: news []On Behalf Of Sylvain Wallez
>>Sent: Sunday, December 21, 2003 11:29 AM
>>Subject: Re: Selectors for Woody FormManager and BindingManager
>>Hugo Burm wrote:
>>>This is about selecting a Form- and BindingManager in Woody.
>>>I want to use my own CustomFormManager instead of
>>>And I want to use my own CustomBindingManager.
>>>So I need the Avalon selector mechanism in the Woody framework
>>for selecting a formmanager and a bindingmanager.
>>>In case somebody asks why I need this: I implemented a
>>template/subform framework. I 'll post about this later.
>>Well, all what's below is "just" plumbing, and you deprive us from the
>>actual meat. Please, please explain ;-)

thx for the explanation.
did you post the patch?

quite a coincidence in fact since I've been exposed to a use case 
recently that also pushes in the direction of having a plugable 

In short: think about a huge apllication-metadata-repository that can be 
consulted online to know what goes on a form (depending on 
user/role/runtime config)...

in these cases it really doesn't make sense to first produce 
(dynamically) the form-definition XML format?

in fact, if I think about using some sort of XML-Schema as a basis for 
the form-definition, then we naturlly end up with more arguments for 
this line of thinking...


> Use case:
> I have 10 screens. Each screen has one form with about 10 questions on each
> screen. That makes 100 questions.
> There  are about five types of questions. Most of them are combined. E.g.
> answer "yes" or "no", and if "yes", then specify the answer in a text field.
> So I need 5 templates or subforms that I can mix and re-use.
> So this is what I "hacked into existence":
> 1) I modified Woody to use a selector for selecting the Form- and
> BindingManager  (this is a standard Avalon approach).
> 2) I wrote my own CustomFormManager, CustomBindingManager, and
> CustomWoodyGenerator. The three of them do all about the same thing: they
> parse a definition file and use cached Woody configuration files as a
> template.
> E.g. the CustomFormManager parses a model file and susbstitutes all template
> placeholders with the stored templates and adjusts id's etc. So the model
> file specifies what templates to use, and in what order.
> This an example of the model file:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <model id="modellist-1" file="forms/model-list.xml">
> <wd:form
>   xmlns:wd=""
>   xmlns:i18n="">
>   <wd:widgets>
> 		<instance id="0"/>
> 		<instance id="1"/>
> 		<instance id="0"/>
>   </wd:widgets>
> </wd:form>
> </model>
> This is the list (model-list.xml) with templates that are cached:
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <list>
> 	<item name="forms/test_model.xml"/>
> 	<item name="forms/test2_model.xml"/>
> </list>
> And the templates are just a standard Woody form definition
> (test_model.xml). Everything within the <wd:widgets> is used for the
> template.
> Thus the CustomFormManager builds the <wd:> Form definition model from the
> files above, The CustomBindingmanager builds the <wb:> binding model. The
> generator generates SAX events and inserts the cached <wt:> templates.

hm, you might consider using the woody-generator in stead

in fact, as a first step into supporting the above described stuff I'm 
well into attemptig to revive the use of the generator for woody ...

my plan is to separate the current woody-template-transformer from his 
configuration features so that separated class can be used from the 
generator as well

as such I hope that future updates on the possibilities of the 
transformer will more naturally flow back to the generator as well?


> Hugo

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message