cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] Comparing Woody & XMLForm : towards a unified form handling (long)
Date Mon, 21 Jul 2003 19:45:08 GMT
Sylvain Wallez wrote:
> Thanks for reading so far. As I expect this post to generate lots of
> discussions, I suggest to create separate threads for particular
> subjects (particularily the final "proposals" chapter) in order to keep
> the discussion focused.
Now, as we all know this is really a "dangerous" topic as such threads might
result in "personal" wars driven by the developers of each part involved.
as Sylvain already pointed out, it's not the reason for this thread to
a "form" war. And personally, I don't think this will happen in Cocoon.

So, I just wanted to throw in my comments as I can only read mails from time
to time and can't really participate in the threads.

One comment I think that is really import came from my collegue, Guido who
said "XForms is a client-side standard", so is it really worth to implement
it in the server? (I hope, it's ok to quote you, Guido...don't blame Guido
for this comment, just me if required!) I don't know the answer, but if
someone would force me to give one, I would tend to say "No".

Now, I really never looked at XMLForms or JXForms, but this doesn't say
anything about their quality etc, it's simply lack of time. But I looked a
little bit at Woody and personally I feel that Woody is really a great
approach by separating form definition from the template. Actually, I
started to implement the same for my test project, looked at Woody and
saw that it already does most of the things I need :)

My ideas of building web applications is a little bit different from what
we have in Cocoon today: In short, I'm thinking of "writing" (whatever
that means) a component for each web page. This component is the controller
for that page and connects (MVC) to the model. A template is used to
render the page. This template uses bindings to insert data into the
The bindings are connected to the component which in turn has access to
the object model. Simple, or?
You have a component EditUser, that has a property user (= method getUser).
You have a template (shortened):
  <input id="surname"/>
  <input id="forename"/>
And the binding
<binding id="surname" type="TextInputField">
<binding id="forename" type="TextInputField">
When the template is processed by the component EditUser, the bindings
are evaluated. So e.g. for the input field surname the binding
is resolved by invoking "getUser()" on the component and "getSurname()" on
the result (JXPath evaluation).
When the submitted form data comes to Cocoon again, the EditUser component
previously creating the form is the one in charge and delegates to the
two input fields. So (without validation) the user is get from the component
and setSurname() resp. setForename() is invoked on the user object.

The plan is to implement two layers of validation, the first layer in the
binding where I can already define obvious validation rules and the second
one in the model, because I think there are cases where only the model can
validate the date. So perhaps a validateSurname() (if existent) might
be invoked on the user.

This is more or less my current idea, and I'm trying to find some time
to see how this fits into Woody. Now, for this thread, let's not discuss
my ideas (I have most of them running already anyway ;) ), this thread
has a different topic. Perhaps my idea from above gives some aspects for
discussion on how to do it - if not, just ignore my ideas...

Speaking of woody, woody has the template already and the form definiton.
Now, what's missing is the binding between the form fields and your
business data.

But, I think this is realy an important thread for Cocoon. IMHO it doesn't
make too much sense to have two (or even more) approaches for the "real form
handling in Cocoon" implement at We should only provide
one good and working solution. Other implementations might exist somewhere
else, but should not here.

So, I think we are on the right track and perhaps combining somehow
both approaches into a new (third) one (named XMoody?) is the distant plan.
If you read this, you might get the impression that I'm +1 for woody and
-1 for XMLForms. But this is not true; I currently only know more about
woody than XMLForms and I have a similar idea, so perhaps I'm a little
bit to biased...


View raw message