You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Hugo Burm <hu...@xs4all.nl> on 2003/12/18 19:32:31 UTC
Selectors for Woody FormManager and BindingManager
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.
These are the required changes for making the selector work (these are
changes to be made by the Woody developers, not by the end-users. This is
transparent for end-users):
1) in woody2.js you have to get your formmanager with one line of additional
code:
var selector =
cocoon.getComponent(Packages.org.apache.cocoon.woody.FormManager.ROLE+"Selec
tor");
var formManager = selector.select("default");
2) Almost the same applies for the createBinding function.
3) In the actions you have to make the same changes as in the flow script.
4) In woody.*.xroles you have to define a "default" hint
5) In woody.*.xconf you must define the widgets for this hint.
I made these changes to -HEAD and tested the Woody samples. Everything seems
to be working as before.
I created a patch. If the Woody committers think this is something that can
make it to HEAD, I will submit it to Bugzilla.
If there are better/easier solutions for switching between different
FormManagers, please let me know.
Hugo Burm
Re: Selectors for Woody FormManager and BindingManager
Posted by Marc Portier <mp...@outerthought.org>.
Hugo Burm wrote:
>
> I was already looking at the generator, because I want to combine inserting
> the templates and doing the first tranformation step. So it will be a good
> thing if the generator is kept in sync with the transformer.
that's the hope, yes
> If you are going to refactor the transformer, have a look at that long
> if-then-else statement in <startElement> and <endElement> and think about
> what is going to happen when more types of widgets arrive...
>
did you mean the WidgetReplacingPipe?
was a bit outside the scope of what I intended to look at here and now
to be honnest
your remark kinda makes me remember this proposed refactoring of those
classes:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106640568220725&w=2
I have to admit I'm clueless on what will happen now, anyone?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
RE: Selectors for Woody FormManager and BindingManager
Posted by Hugo Burm <hu...@xs4all.nl>.
> From: Marc Portier [mailto:mpo@outerthought.org]
> Sent: Monday, December 22, 2003 12:07 PM
> To: dev@cocoon.apache.org
> Subject: Re: Selectors for Woody FormManager and BindingManager
>
>
> 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?
>
Agree. I now must dynamically build the XML form- and binding-model and then
feed it back into a parser, which doesn't make sense.
>
> >
> > 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?
I was already looking at the generator, because I want to combine inserting
the templates and doing the first tranformation step. So it will be a good
thing if the generator is kept in sync with the transformer.
If you are going to refactor the transformer, have a look at that long
if-then-else statement in <startElement> and <endElement> and think about
what is going to happen when more types of widgets arrive...
Hugo
Re: Selectors for Woody FormManager and BindingManager
Posted by Marc Portier <mp...@outerthought.org>.
Hugo Burm wrote:
>>From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
>>Sent: Sunday, December 21, 2003 11:29 AM
>>To: dev@cocoon.apache.org
>>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/
mpo@outerthought.org mpo@apache.org
RE: Selectors for Woody FormManager and BindingManager
Posted by Hugo Burm <hu...@xs4all.nl>.
> From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
> Sent: Sunday, December 21, 2003 11:29 AM
> To: dev@cocoon.apache.org
> 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 ;-)
>
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.
Hugo
Re: Selectors for Woody FormManager and BindingManager
Posted by Sylvain Wallez <sy...@apache.org>.
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 ;-)
>These are the required changes for making the selector work (these are changes to be made by the Woody developers, not by the end-users. This is transparent for end-users):
>1) in woody2.js you have to get your formmanager with one line of additional code:
> var selector = cocoon.getComponent(Packages.org.apache.cocoon.woody.FormManager.ROLE+"Selector");
> var formManager = selector.select("default");
>2) Almost the same applies for the createBinding function.
>3) In the actions you have to make the same changes as in the flow script.
>4) In woody.*.xroles you have to define a "default" hint
>5) In woody.*.xconf you must define the widgets for this hint.
>
>I made these changes to -HEAD and tested the Woody samples. Everything seems to be working as before.
>
>I created a patch. If the Woody committers think this is something that can make it to HEAD, I will submit it to Bugzilla.
>
>
All this sounds good, but tell us more about your use case!
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