Hugo Burm wrote:

From: news [mailto:[EMAIL PROTECTED] Behalf Of Sylvain Wallez
Sent: Sunday, December 21, 2003 11:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Selectors for Woody FormManager and BindingManager


Hugo Burm wrote:



Hello,

This is about selecting a Form- and BindingManager in Woody.
I want to use my own CustomFormManager instead of

"org.apache.cocoon.woody.DefaultFormManager".


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

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

wdyt?



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="http://apache.org/cocoon/woody/definition/1.0";
  xmlns:i18n="http://apache.org/cocoon/i18n/2.1";>
  <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?


wdyt? -marc=

Hugo



-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]



Reply via email to