cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 14:45:09 GMT

Carsten Ziegeler wrote:
> I have read most of the RT and think I have understand some parts of it.
> Now, I agree that keeping the field definitons as short and comprise
> as possible is good.
> Now - without reading more of all the discussions and looking into
> woody - I just wanted to throw in some aspects which I think are
> currently not covered.
> Binding
> -------
> I think the most important part is the binding to an existing
> business model (= java objects).

there is a sample now doing that, above statement leaves it 
unclear if you tried that or not

> I haven't looked at the current binding implementation and therefore
> can't say much about it.
> But my experiments showed that JXPaths is good but not good enough
> and I'm currently planning to improve JXPaths in some respects.

sounds intersting (but vague: looking forward)

> The following notes are all tied to bindings:
> Datatypes
> ---------
> The explicit definition of datatypes in Woody is good, but I still
> think not needed if your form is bound to your strongly typed
> business model.

actually the form-definition-datatyping is there for another 
reason: we can't derive the types from the 
http-request-paramaters :-(

if I understand what you are saying, then you would want to have 
the form definition (structure, fields, datatypes and convertors) 
  deduced from the (runtime?) introspection of the business model?

I (currently) don't think such is possible,

my own thinking towards some of this was more in the direction of 
using something like xdoclet to deduce this information from the 
extra @javadoc-attribuation of the source code and use that to 
generate the required woody-definition files

> For example if your field is bound to an int everything is said
> by this type (except any additional validation like range checks).
> So, I think the datatypes must be more optional and could be
> taken from the bound object model (if any).
> Validation
> ----------
> It's good to have the possibility to define validation in the form
> and at the fields. But in some cases your business objects can
> validate their values as well and you don't want to code it twice.


> Simple Example: Imagine you have a user object with an age property
> modelled by an int. Now, it's only valid to set an age from 0 to 256.
> The business objects should check for valid values. One possibility
> could be by adding a validateAge(int) method to the user object,
> so it has three methods setAge, getAge and validateAge (where the
> last is optional).
> So (in conjunection with the binding) the validateAge method could be
> invoked to check if the value is valid. This allows validating values
> before they are set on the business objects. In case of an validation
> error the values should not be set using setAge() etc.
> Now, this is one idea I have. The other one deals with validation on
> complete business objects where perhaps one property depends on
> another. In this case, the form handling framework could start a
> "transaction". It first fetches all old values of the business objects,
> sets the new values and invokes the validation (validate() method
> on the business object?). When the validation is ok, the 
> transaction is finished. If the validation fails, the transaction
> is rolled back and the old values are restored.
> These are only some thoughts, but for me the most important part
> is the binding and the interaction between the form handling and
> the business model.

That's an area that is holding a lot of my concern as well, and 
in my web-app-dev-carreer it is not the first time that I'm 
looking for a solution to this (as it is most likely the case on 
your side)

my experience in this (and although that sounds like accumulated 
history I realize that expressed experience is a very momentary 
snapshot) is that the attempts often try to do too much at once

a lot of the cases you describe above are (from a web POV) to be 
considered as 'arbitrary complex' and 'totally backend specific' 
meaning you are bound to need just specific code to deal with it 
at some point in time

IMHO the introduction of the itermediate woody-form-model 
introduces an insulation layer between web-based-form-handling 
and the arbitrary logic that deals with the processing of the 
filled in form...

the web-based-form-handling-features end up being whatever we 
want the woody framework to do, that is with a focus on the 
visual side of things and as such try to provide a model for say 
90% of all web-forms out there (I did not say web-apps, I said 
web-forms)  - as we currently see it people expect this layer to 
(optionally) handle quite some entry-validation and 
datatype-conversion to easily hook up the other part:

still IMHO that 'processing of the filled in form' involves
1/ reading out what was put into the form and
2/ possibly applying custom and domain specific validations 
(calling even the backend to do the validation for you)
3/ putting variables filled in the form to backend-specific 

it depends totally on your backend how this will look like
(in which order, which backend calls, ...)

and the 'binding' as done now is really something that can help 
this arbitrary logic by declaratively dealing with the 1/ to 3/ 

I'm _unsure_ if we can extend that (in general) towards doing the 
totally arbitrary stuff I'm afraid of in 2/ but maybe some 
example from your part clarifies better what you want to achieve?

However I am quite _sure_ that we shouldn't mix-up the general 
positioning of the binding: it is a mapping-aid for arbitrary 
back-end logic, it is NOT part of the web-form-handling

The line is thin of course: a 'generic' action or flow-script 
that takes form-def and binding-def and maybe some other stuff as 
parameters could be introducing a most-cases logic way of doing 
things... it is just not that I believe this could be extended to 
cover all cases?  It would serve as a good example, but not 
classify as a part of the framework?

See, towards the browser we can do stuff: there is a 
pattern/standard shared among the browsers.... towards the 
backend its way out freaking everything that can happen.

Binding is fun and can be an aid (and without it people were not 
likely to even consider woody to be useful),

I'm open to suggestions to make it more usuable and widely 
applicable, but we should never expect it to do everything 
imaginable (meaning: you have your choice of flow-implementation 
to host that part of the logic?)

> Carsten
> Sylvain Wallez wrote:
>><snip great RT/>

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message