cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] New Input for woody
Date Thu, 31 Jul 2003 15:25:08 GMT
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


Mime
View raw message