Sylvain Wallez wrote:
Andreas Hochsteger wrote:
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML input fields?
We are currently using three input fields for dates (day, month, year) at our current form solution.
Thanks for clearification!
Marc explained how this can technically occur using AggregatedField.
Now from a more semantical point of view, AggregateField is something I'm not very comfortable with. Let's consider its two use cases :
1/ Phone number example
In this example, the displayed form shows only one input box, and its value is split into several non-visual subfields used by the application (country code, area code, number). Do these non-visual subfields really belong to the form definition if it never displays them ? Doesn't this split belong to the binding more than to the form definition ?
2/ Date split in several inputs
The day/month/year inputs are just a particular visual implementation of a date widget (in the GUI meaning of "widget"). What if we finally decide to use a calendar popup instead of 3 inputs ? Do we have to change all form definitions ?
Maybe that's just nitpicking, but I find this somewhat breaks Woody's clean SoC.
Touché.
Indeed: The aggregatefield was only introduced when we started thinking about binding... however, by now I have learned to appreciate the concept as having its own value in the woody-model
You are right: it does somewhat hook up some back-end business-model vision onto the form-fields... but then again the (other) discussion we are having on the business-model-specific datatyping and even business-model-specific-validation does introduce the same level of mixing, no?
And while we try to manage the good SoC here, the reality of the app will always be that people *know* (influenced by their business-domain knowledge on the app they write) about these aggregations when they model the form. And not unlikely the form will need to be able to exploit that knowledge.
(In fact I guess that the reality vision expressed above is the real drive behind your current effort to make Woody more lightweight and generally usable?)
Purely technical I have also the following argument: I expressed earlier that the Woody model should be seen as the insulation layer between how the end user sees things and how the business-models need to be presented... now, I'm ready to change that into: it is the insulation-POINT where the two worlds are meeting.
The Woody form-model is what sits in between how the end-user consumes and edits his HTML-form and how the back-end presents and expects business data...
On the HTML form there is weak typing (only strings) and weak structuring (only a map-like structure of request-params) compared to the back-end view of things (rigid structure of staticly typed values)
The Woody-form-model takes up the responsibility of making the match between both, therefor it largely needs to know everything about both! (maybe this explains why it is perceived heavy at first glance?)
So it needs
- datatype knowledge and convertors (doing the string to YourType in 2 directions)
- validation rules (making sure we're not handing over gibberish to the backend-model)
- mapping pointers into the backend-structure (binding)
- ...
What the introduction of the Aggregate-field is adding to the show is something I would call 'granularity of information', and to date I'm convinced that the woody-model needs to be aware of the smallest granularity either it be imposed by the end-user view or the back-end structure:
1/ phone number example:
end-user sees 1 field
back-end expects 3 distinct ones (ctr, zone, local)
--> imposed granularity == 32/ date example
end-user sees 3 fields (day, month, year)
back-end expects 1
--> imposed granularity == 3The above also illustrates that the usage of the aggregate-field will only be useful to people actually having the intent to map stuff onto a backend-business model.
(but by now we already aggreed(?) that such is not really tied to actually using the declarative data mapping provided by the binding)
What do you think?
I also like the practical consequences introduced by the aggregate-field notion:
- it becomes a template-designer choice to present the date as one field or as separate fields
- it allows for (maybe easier) validation rules on the split parts
- it made writing the binding-stuff so easy that I could do it :-) (now you see how I do all effort not to overload Bruno ;-))
-marc= (in elaboration mode again, you all must think I get paid by the word)
--
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]
