cocoon-dev mailing list archives

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.
>
agree
> 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
object-models
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/
mapping....
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/>
>
>
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