cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject [RT] New Input for woody
Date Thu, 31 Jul 2003 09:57:49 GMT
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


Mime
View raw message