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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
