You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/07/31 11:57:49 UTC
[RT] New Input for woody
I think we all know how woody works (apart from me...), so perhaps
I could give some details about my idea. I don't want to propose this
as an alternative to woody, I just want to give some input. So here we go:
The idea is based on a separation between a template and
a definition or binding for it. It's a little bit
like woody but also different :)
Here is a template example:
<page xmlns:dywel="http://zis.de/cocoon/dywel/0.1">
<dywel:DWForm id="form">
<dywel:DWTextField id="name"/>
<dywel:DWTextField id="street"/>
<dywel:DWTextField id="city"/>
<dywel:DWSubmit id="submit"/>
</dywel:DWForm>
</page>
Now, I think apart from namespace and element names this looks
like a woody template (except form and submit).
The difference lies in the second configuration file, that I
call binding. It has an entry for each field used in the template:
<dywel:bindings xmlns:dywel="http://zis.de/cocoon/dywel/0.1">
<dywel:binding id="form">
<action>nextPage</action>
</dywel:binding>
<dywel:binding id="submit">
<value>Submit</value>
</dywel:binding>
<dywel:binding id="name">
<value>user.name</value>
</dywel:binding>
<dywel:binding id="city">
<value>user.address.city</value>
</dywel:binding>
<dywel:binding id="street">
<value>user.address.city</value>
</dywel:binding>
</dywel:bindings>
How does it work? A component (a java implementation) parses
the template and the binding file, the first time it's used.
The template is compiled and the bindings are attached to
the internal tree representing the template.
A special generator uses the java component and asks it to
render the page. Now the tree is processed. Each field
knows how to render itself. To get the values for a
form field, the field asks the component for the
value for e.g. "user.name". The component now has
a getUser() method and the returned user object has
a getName() method.
When the form is submitted, the same tree is processed and
the fields set the values using the component, so
getUser().setName() is used etc.
It's also possible to test via getUser().validateName()
etc.
For each form or better web page, you have to write
the java component = controller. You simply inherit
from a base class and provided methods to get your
business objects. (I'm looking to simplify this using
fom when everything else is set).
So, this solution is tied to java objects (currently).
Now, it is possible to specify additional validation and
formatting in the binding, like:
<dywel:binding id="street">
<value>user.address.city</value>
<validation>a rule</validation>
<formatter>a formatter</formatter>
</dywel:binding>
etc.
This works pretty well (for me). Now I think this approach has
two advantages. The people writing the template do not have to
know anything about the binding, they simply create the
page and insert a username field (same applies to woody).
But the same mechanism is also used to insert values into the template,
it's not restricted to form fields:
<dywel:DWString id="username"/>
and the binding
<dywel:binding id="username">
<value>user.name</value>
</dywel:binding>
The same works with repetitions etc.
As it doesn't make sense to have soo many different approaches for
form handling, I just wanted to integrate woody somehow rather
than write everything again.
So I guess the template is not the problem, replacing the namespaces
and the element names et voila.
The compilation of the template I currently use can cope with this
I guess. Now the problem is my binding. It's different from the
way woody defines things.
Thoughts?
Carsten
RE: [RT] New Input for woody
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Antonio Gallardo wrote:
>
> The idea looks great. A business oriented framework!
>
> What can we also use to use to send mails under this framework? Sometimes
> there is a need to send a automatic email notifications of some changes.
> But of course we can use other approach to do this maybe encapsulated into
> the business objects.
>
You can either use one of the existing other approaches or you can send
the mail from within your java code.
> Are you thinking in persistence? How you mean this will be done? I will be
> glad if we can exchange some ideas between this.
>
Yes, persistence is the key feature. Now currently you can use whatever
you want, hibernate, ojb etc. I don't want to create a layer inbetween
and I don't want to force others to use one over the other.
I just started to look at those two and currently I like ojb more. I
guess I will have to throw my ideas for some improvements into the ojb
list and see what happens.
Persistence is a separate concern so I don't want to solve this in Cocoon.
If you or me or anyone else has specific requirements for persistence
than we/you/he should try to get in contact with one of the persistence
development teams.
> I am currenlty spending my time trying to find a new way. The idea of
> create business objects. Maybe we can create a more generalized interface
> to do that. I am also facing the raping changes in the Woody arena. But it
> is OK. I am glad Woody that woody runs too fast!
>
> Currently I am starting to try Woody with Beans (or may we can call it
> ValueObjects)?
Ok, I'm interested to see the results.
>
> You can also download the lastest CVS of OJB because there is a very nice
> presentation that was posted 2 or 3 days ago. I think it is a worth to see
> it. At the end it show how we can abstract the Data Access Tier.
>
I donwloaded the latest rc and it took me some hours yesterday night to get
it
running. I ported my test app from hibernate to ojb and it wasn't that easy
because hibernate has some nice features ojb does not have and vice versa.
Carsten
RE: [RT] New Input for woody
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Carsten Ziegeler dijo:
> My approach is targetted at editing business objects (=java objects).
> It's not used for editing xml data or for processing form values in others
> ways, like sending emails etc.
Hi Carsten:
The idea looks great. A business oriented framework!
What can we also use to use to send mails under this framework? Sometimes
there is a need to send a automatic email notifications of some changes.
But of course we can use other approach to do this maybe encapsulated into
the business objects.
Are you thinking in persistence? How you mean this will be done? I will be
glad if we can exchange some ideas between this.
I am currenlty spending my time trying to find a new way. The idea of
create business objects. Maybe we can create a more generalized interface
to do that. I am also facing the raping changes in the Woody arena. But it
is OK. I am glad Woody that woody runs too fast!
Currently I am starting to try Woody with Beans (or may we can call it
ValueObjects)?
You can also download the lastest CVS of OJB because there is a very nice
presentation that was posted 2 or 3 days ago. I think it is a worth to see
it. At the end it show how we can abstract the Data Access Tier.
Best Regards,
Antonio Gallardo.
>
> That's why I still think that it makes sense to follow the dywel
> approach but I want to use underneath as much as possible from the
> existing features we already have.
>
> Carsten
RE: [RT] New Input for woody
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bruno Dumon wrote:
> > Thoughts?
>
> Just a quick one: you're assuming there actually is a bean. Or to put it
> in another way: to create a "dywel" form, you also need to create a
> bean. Makes me think a lot of Struts' "form beans" again (i.e. beans
> created especially for form handling). One of the goals behind Woody was
> to make it possible to create forms without necessarily writing a
> bean...
>
Not exactly (also it might be wording), you have to create a component
that might use beans but doesn't have to.
But in general, yes you're right. My approach is targetted at editing
business objects (=java objects). It's not used for editing xml data
or for processing form values in others ways, like sending emails etc.
That's why I still think that it makes sense to follow the dywel approach
but I want to use underneath as much as possible from the existing
features we already have.
Carsten
Re: [RT] New Input for woody
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-07-31 at 11:57, Carsten Ziegeler wrote:
<snip/>
>
> Thoughts?
Just a quick one: you're assuming there actually is a bean. Or to put it
in another way: to create a "dywel" form, you also need to create a
bean. Makes me think a lot of Struts' "form beans" again (i.e. beans
created especially for form handling). One of the goals behind Woody was
to make it possible to create forms without necessarily writing a
bean...
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [RT] New Input for woody
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-07-31 at 17:25, Marc Portier wrote:
<snip/>
>
> As I see it now, the integration is not trivial (but possible)
> Your bean seems to provide an alternative to the declarative
> woody-widget tree (form-model)
>
> We could argue about the woody-widget tree being the real CORE of
> woody, so the 'not trivial' gets to have some meaning I guess :-)
>
> 'Integration' then becomes making the form-model pluggable which
> would come down to
> 1/ making the woody-template-transformer can pull out the values
> using jxpath rather then using the widget API
> 2/ and the other way around the form.process(request) needs to
> evolve to Dywel.process(bean-or-widgetTree, request); which could
> again use some jxpath-like approach to perform its setValues...
>
> not trivial, maybe possible, useful?
_very_ quick skim-read, but: didn't you just reinvent XMLForm?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: [RT] New Input for woody
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Marc Portier wrote:
>
> > Carsten,
> >
> > Thx. This extra explanation on dywel added onto the understanding I
> > already had (important nuances noted)
> >
> >>> not trivial, maybe possible, useful?
> >>
> >>
> >> Hmm, I'm a little unsure. Now, I don't want to destroy the design of
> >> woody only to make me happy. If it makes sense, to change woody:
> >> great. If it doesn't, well, then I can live with that as well. It's a
> >> decision I'm currently not able to make or contribute to.
> >
>
> I'm not sure Woody's design has to be destroyed to include Dywel's way
> of binding. With the upcoming separate datatype and format catalogues,
> it would be possible to write an implementation that builds the datatype
> catalogue using introspection.
>
> Same applies to binding : there can be another implementation of the
> binding.
Sounds good!
>
>
> > The resemblence is a great way IMO to realize none of us is completely
> > on the wrong track, but it can't prevent the different alternatives to
> > take specific differentiating positions that will make them more
> > elegant to use in very specific situations.
> >
> > Woody has everything in it to grow into a system that can handle your
> > bean backends equally well as pure XML backends given the loose
> > connection ideas to be found everywhere in the design...
> >
> > There surely is the commitment (effort currently going on if you ask
> > me) to ensure that specific broadly recognised usage models could get
> > a simplified mapping onto the current Woody-soc...
>
>
> Yep. Woody is currently able to map to XML and JavaBean backends, which
> should already cover many of the needs. Another need I foresee is direct
> mapping to an SQL backend.
>
This sounds a little bit like mixing concerns, but let's see how it comes
out.
> > but rest assured: none of that effort will ever ensure that in a given
> > case there could not be a more specific implementation that will be
> > able to cut some corners and provide a more elegant solution.
> >
> > The above statement probably fits to a large extend to what Cocoon as
> > a whole is providing. (and how it is sometimes perceived)
> >
> > In any case, thx for your input, it already added some nice features
> > into the woody-basket (and possibly touching woody returned you some
> > of the favor).
> >
> > I hope you can continue the effort of feeding us your progress
> on Dywel.
>
>
> Yes, please. And keep following the work on Woody. You may find that it
> is able to host your ideas as particular implementations of one of its
> components.
>
Yes, of course I will do both. And I thank you all for trying to explain
Woody to me and to see how dywel and woody might fit together.
Perhaps we will see at a later time when both things will be used how the
real implementation should look like (perhaps for Cocoon 3.1).
Thanks
Carsten
Re: [RT] New Input for woody
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
> Carsten,
>
> Thx. This extra explanation on dywel added onto the understanding I
> already had (important nuances noted)
>
>>> not trivial, maybe possible, useful?
>>
>>
>> Hmm, I'm a little unsure. Now, I don't want to destroy the design of
>> woody only to make me happy. If it makes sense, to change woody:
>> great. If it doesn't, well, then I can live with that as well. It's a
>> decision I'm currently not able to make or contribute to.
>
I'm not sure Woody's design has to be destroyed to include Dywel's way
of binding. With the upcoming separate datatype and format catalogues,
it would be possible to write an implementation that builds the datatype
catalogue using introspection.
Same applies to binding : there can be another implementation of the
binding.
>> I think, currently if Dywel will ever work sometime in the distant
>> future, it's more elegant to connect to existing business objects
>> than woody; but on the other hand woody has great advantage in all
>> the other form areas where you don't connect to business objects.
>>
>
> I agree.
>
> That all of this largely resembles each other (Bruno saying I
> reinvented xmlforms adds to that) should be no big surprise since all
> of it tries to solve the same set of problems...
I would add that it's good that you reinvented XMLForm : there are nice
ideas in it, but it's hardly usable for serious formatting and
connection to back-end data. Every framework builds on the lessons taken
from the previous one. And when good ideas exist, there's no reason to
trash them.
> The resemblence is a great way IMO to realize none of us is completely
> on the wrong track, but it can't prevent the different alternatives to
> take specific differentiating positions that will make them more
> elegant to use in very specific situations.
>
> Woody has everything in it to grow into a system that can handle your
> bean backends equally well as pure XML backends given the loose
> connection ideas to be found everywhere in the design...
>
> There surely is the commitment (effort currently going on if you ask
> me) to ensure that specific broadly recognised usage models could get
> a simplified mapping onto the current Woody-soc...
Yep. Woody is currently able to map to XML and JavaBean backends, which
should already cover many of the needs. Another need I foresee is direct
mapping to an SQL backend.
> but rest assured: none of that effort will ever ensure that in a given
> case there could not be a more specific implementation that will be
> able to cut some corners and provide a more elegant solution.
>
> The above statement probably fits to a large extend to what Cocoon as
> a whole is providing. (and how it is sometimes perceived)
>
> In any case, thx for your input, it already added some nice features
> into the woody-basket (and possibly touching woody returned you some
> of the favor).
>
> I hope you can continue the effort of feeding us your progress on Dywel.
Yes, please. And keep following the work on Woody. You may find that it
is able to host your ideas as particular implementations of one of its
components.
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
Re: [RT] New Input for woody
Posted by Marc Portier <mp...@outerthought.org>.
Carsten,
Thx. This extra explanation on dywel added onto the understanding
I already had (important nuances noted)
>>not trivial, maybe possible, useful?
>
> Hmm, I'm a little unsure. Now, I don't want to destroy the design
> of woody only to make me happy. If it makes sense, to change
> woody: great. If it doesn't, well, then I can live with that
> as well. It's a decision I'm currently not able to make or
> contribute to.
>
> I think, currently if Dywel will ever work sometime in the distant
> future, it's more elegant to connect to existing business objects
> than woody; but on the other hand woody has great advantage in
> all the other form areas where you don't connect to business objects.
>
I agree.
That all of this largely resembles each other (Bruno saying I
reinvented xmlforms adds to that) should be no big surprise since
all of it tries to solve the same set of problems...
The resemblence is a great way IMO to realize none of us is
completely on the wrong track, but it can't prevent the different
alternatives to take specific differentiating positions that will
make them more elegant to use in very specific situations.
Woody has everything in it to grow into a system that can handle
your bean backends equally well as pure XML backends given the
loose connection ideas to be found everywhere in the design...
There surely is the commitment (effort currently going on if you
ask me) to ensure that specific broadly recognised usage models
could get a simplified mapping onto the current Woody-soc...
but rest assured: none of that effort will ever ensure that in a
given case there could not be a more specific implementation that
will be able to cut some corners and provide a more elegant solution.
The above statement probably fits to a large extend to what
Cocoon as a whole is providing. (and how it is sometimes perceived)
In any case, thx for your input, it already added some nice
features into the woody-basket (and possibly touching woody
returned you some of the favor).
I hope you can continue the effort of feeding us your progress on
Dywel.
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
RE: [RT] New Input for woody
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Marc Portier wrote:
>
> <snip/>
> as I understood from earlier discussions this also serves as a
> form-model-definition (meaning dywel doesn't require an aditional
> file for that)
More or less: yes - you need the "binding".
> >
> > How does it work? A component (a java implementation) parses
> > the template and the binding file, the first time it's used.
> > The template is compiled and the bindings are attached to
> > the internal tree representing the template.
> >
>
> could you elaborate on 'attached'
> is an instance of the business object involved in this process?
No, a tree is created is created with java objects for the different
elements or fields used. So you have a java object representing
one particular input field. This object gets the binding, so
it knows from where to get it's input. But this is only the
definition, so the object does not get the business object
itself only the string like "user.name".
> > A special generator uses the java component and asks it to
> > render the page. Now the tree is processed. Each field
> > knows how to render itself. To get the values for a
> > form field, the field asks the component for the
> > value for e.g. "user.name". The component now has
> > a getUser() method and the returned user object has
> > a getName() method.
> >
>
> this sounds like the business object instance values are only
> read at this time...
>
Exactly. The tree I mentioned above is traversed and the java
object for the field gets a "component" and can ask that
component for the value of let's say "user.name".
>
> > For each form or better web page, you have to write
> > the java component = controller. You simply inherit
> > from a base class and provided methods to get your
> > business objects. (I'm looking to simplify this using
> > fom when everything else is set).
> > So, this solution is tied to java objects (currently).
> >
>
> well, it is tied to a custom-to-be-written java object
>
> from a distance it looks like you'll need some luck for hooking
> up some existing java objects from a long-before-dywel designed
> business application (e.g. the validation method, but also the
> type of the argument in the setXXX methods, the web is presenting
> you with Strings, how is the conversion done? <-- this is the
> crux of my current understanding of dywel)
Ah, ok, you don't need something in between you can directly connect
to existing business objects. E.g. JXPath can do most of the
conversions for you, if you have a string with a number and have
a setAge(int) the conversion is done for you automatically etc.
So most conversions can be done by that, you can set optional
formatter objects in the binding that do the conversion for you,
e.g. for date objects.
>
> if that is the case then one is going to need to write a specific
> javabean to accomodate for the intermediate step before actually
> talking to the legacy backend system
No, as explained above.
>
> woody's proposition is to use not Java code but the
> form-definition file to describe this intermediate model... AFAIU
> both approaches use this kind of intermediate stage as a basis
> for validation and string-type conversion
>
> (remembering Bruno's recent rumblings on jxpath addressing inside
> form-widgets the line could get very thin)
>
> > Now, it is possible to specify additional validation and
> > formatting in the binding, like:
> > <dywel:binding id="street">
> > <value>user.address.city</value>
> > <validation>a rule</validation>
> > <formatter>a formatter</formatter>
> > </dywel:binding>
> >
> > etc.
>
> similar
>
> I'm still looking for the reverse of the formatter (string to type?)
The formatter does both.
>
> As I see it now, the integration is not trivial (but possible)
> Your bean seems to provide an alternative to the declarative
> woody-widget tree (form-model)
>
> We could argue about the woody-widget tree being the real CORE of
> woody, so the 'not trivial' gets to have some meaning I guess :-)
>
> 'Integration' then becomes making the form-model pluggable which
> would come down to
> 1/ making the woody-template-transformer can pull out the values
> using jxpath rather then using the widget API
> 2/ and the other way around the form.process(request) needs to
> evolve to Dywel.process(bean-or-widgetTree, request); which could
> again use some jxpath-like approach to perform its setValues...
>
> not trivial, maybe possible, useful?
Hmm, I'm a little unsure. Now, I don't want to destroy the design
of woody only to make me happy. If it makes sense, to change
woody: great. If it doesn't, well, then I can live with that
as well. It's a decision I'm currently not able to make or
contribute to.
I think, currently if Dywel will ever work sometime in the distant
future, it's more elegant to connect to existing business objects
than woody; but on the other hand woody has great advantage in
all the other form areas where you don't connect to business objects.
Carsten
Re: [RT] New Input for woody
Posted by Marc Portier <mp...@outerthought.org>.
Carsten,
it took me some time to read and re-read and map:
I kinda heard the implied question 'how to map this on woody' so
I'll basically try to answer that...
Carsten Ziegeler wrote:
> I think we all know how woody works (apart from me...), so perhaps
> I could give some details about my idea. I don't want to propose this
> as an alternative to woody, I just want to give some input. So here we go:
>
> The idea is based on a separation between a template and
> a definition or binding for it. It's a little bit
> like woody but also different :)
>
> Here is a template example:
>
> <page xmlns:dywel="http://zis.de/cocoon/dywel/0.1">
> <dywel:DWForm id="form">
> <dywel:DWTextField id="name"/>
> <dywel:DWTextField id="street"/>
> <dywel:DWTextField id="city"/>
>
> <dywel:DWSubmit id="submit"/>
> </dywel:DWForm>
> </page>
>
> Now, I think apart from namespace and element names this looks
> like a woody template (except form and submit).
>
yep
as I understood from earlier discussions this also serves as a
form-model-definition (meaning dywel doesn't require an aditional
file for that)
> The difference lies in the second configuration file, that I
> call binding. It has an entry for each field used in the template:
>
> <dywel:bindings xmlns:dywel="http://zis.de/cocoon/dywel/0.1">
>
> <dywel:binding id="form">
> <action>nextPage</action>
> </dywel:binding>
> <dywel:binding id="submit">
> <value>Submit</value>
> </dywel:binding>
> <dywel:binding id="name">
> <value>user.name</value>
> </dywel:binding>
> <dywel:binding id="city">
> <value>user.address.city</value>
> </dywel:binding>
> <dywel:binding id="street">
> <value>user.address.city</value>
> </dywel:binding>
>
> </dywel:bindings>
>
> How does it work? A component (a java implementation) parses
> the template and the binding file, the first time it's used.
> The template is compiled and the bindings are attached to
> the internal tree representing the template.
>
could you elaborate on 'attached'
is an instance of the business object involved in this process?
this sounds like what woody does with the form-definition file:
build up an internal tree that represents the form and knows
about the rich datatypes of the back-end
> A special generator uses the java component and asks it to
> render the page. Now the tree is processed. Each field
> knows how to render itself. To get the values for a
> form field, the field asks the component for the
> value for e.g. "user.name". The component now has
> a getUser() method and the returned user object has
> a getName() method.
>
this sounds like the business object instance values are only
read at this time...
souds like woody's Binding.loadFormFromModel()
> When the form is submitted, the same tree is processed and
> the fields set the values using the component, so
> getUser().setName() is used etc.
> It's also possible to test via getUser().validateName()
> etc.
the idea in Woody is that the commit only reaches up to the
form-model, copying over to the business-model is a different
decision (controlled by flow typically, and possibly via the
assistance of the declarative data-mapping of the 'binding')
(the same 'binding' word depicts a different concept in the woody
vs dywel namespaces, vaguely related, but different IMO)
> For each form or better web page, you have to write
> the java component = controller. You simply inherit
> from a base class and provided methods to get your
> business objects. (I'm looking to simplify this using
> fom when everything else is set).
> So, this solution is tied to java objects (currently).
>
well, it is tied to a custom-to-be-written java object
from a distance it looks like you'll need some luck for hooking
up some existing java objects from a long-before-dywel designed
business application (e.g. the validation method, but also the
type of the argument in the setXXX methods, the web is presenting
you with Strings, how is the conversion done? <-- this is the
crux of my current understanding of dywel)
if that is the case then one is going to need to write a specific
javabean to accomodate for the intermediate step before actually
talking to the legacy backend system
woody's proposition is to use not Java code but the
form-definition file to describe this intermediate model... AFAIU
both approaches use this kind of intermediate stage as a basis
for validation and string-type conversion
(remembering Bruno's recent rumblings on jxpath addressing inside
form-widgets the line could get very thin)
> Now, it is possible to specify additional validation and
> formatting in the binding, like:
> <dywel:binding id="street">
> <value>user.address.city</value>
> <validation>a rule</validation>
> <formatter>a formatter</formatter>
> </dywel:binding>
>
> etc.
similar
I'm still looking for the reverse of the formatter (string to type?)
>
> This works pretty well (for me). Now I think this approach has
> two advantages. The people writing the template do not have to
> know anything about the binding, they simply create the
> page and insert a username field (same applies to woody).
> But the same mechanism is also used to insert values into the template,
> it's not restricted to form fields:
>
> <dywel:DWString id="username"/>
>
woody needs the proposed 'output' (or readonly) widget to support
the same
> and the binding
>
> <dywel:binding id="username">
> <value>user.name</value>
> </dywel:binding>
>
> The same works with repetitions etc.
>
> As it doesn't make sense to have soo many different approaches for
> form handling, I just wanted to integrate woody somehow rather
> than write everything again.
>
As I see it now, the integration is not trivial (but possible)
Your bean seems to provide an alternative to the declarative
woody-widget tree (form-model)
We could argue about the woody-widget tree being the real CORE of
woody, so the 'not trivial' gets to have some meaning I guess :-)
'Integration' then becomes making the form-model pluggable which
would come down to
1/ making the woody-template-transformer can pull out the values
using jxpath rather then using the widget API
2/ and the other way around the form.process(request) needs to
evolve to Dywel.process(bean-or-widgetTree, request); which could
again use some jxpath-like approach to perform its setValues...
not trivial, maybe possible, useful?
> So I guess the template is not the problem, replacing the namespaces
> and the element names et voila.
> The compilation of the template I currently use can cope with this
> I guess. Now the problem is my binding. It's different from the
> way woody defines things.
>
as explained above both usages of 'binding' are about different
things:
the equivalent of woody-binding in dywel terms would cover a
declarative mapping of the data from your bean towards the actual
business backend model (where I still assume dywel will need some
'luck' to be usable _directly_ on any arbitrary existing backend
model...)
> Thoughts?
>
above, hope my analysis is correct
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org