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�.
;-) Actually, this is something I was uncomfortable with right from the beginning, but did not want to throw on the table immediately as it's rather peripheral.
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?
Yes and no. Yes, because business-model-specific-validation introduces the application into the form definition, but no as it does not impact the structure of the form (i.e. the number of widgets it contains).
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 == 3
2/ date example end-user sees 3 fields (day, month, year) back-end expects 1 --> imposed granularity == 3
The 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?
This technically makes sense, but I'm not comfortable with the actual widget implementation having an impact on the form definition...
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
In fact, I think there can be various interpretation of the "template-designer" role. It seems like you consider the template designer more like an HTML-guy, while I my experience shows that he's more an application-domain-related guy.
What I'd like to achieve is to have the form template define the overall form layout (fieldsets, columns, etc) but not the details of the layout, especially for low-level widgets. IMO, the form designer should not have to worry about the fact that the date input is actually implemented using a combination of 3 popups instead of a single input. Moreover, requiring the form designer to explicitely write these 3 popups in the template each time a date input is needed will certainly lead to inconsistencies in the GUI.
So actually, what I'd like to see in the form template for this date example is :
<wt:field id="startDate"><date/></wt:field>
<wt:field id="endDate"><date/></wt:field>
Which should be expanded into : <wi:field id="birthDate"> <wi:style><date/></wi:style> <wi:field id="birthDate.year"/> <wi:field id="birthDate.month"/> <wi:field id="birthDate.day"/> </wi:field>
<wi:field id="endDate"> <wi:style><date/></wi:style> <wi:field id="birthDate.year"/> <wi:field id="birthDate.month"/> <wi:field id="birthDate.day"/> </wi:field>
This can be easily achieved if we consider two types of AggregateField that are SAXed differently :
- app-related aggregation (phone-number) : child fields are non-visual, an only the aggregating widget is output
- GUI-related aggregation (date) : child fields are visual, but not explicitely written in the template, and the aggregating widet SAXes them as part of it's own SAX production.
Now we still have a problem on the form-definition part : just as it would be painful to write all 3 subfields in the template each time we have a date, it is also painful to write them in the form declaration. Plus the usual consistency problems.
After the datatype and format catalogues, what is coming here is a catalogue for reusable field definitions !
Catalogue :
<wd:aggregate-field id="date-template">
<wd:field id="year"/>
<wd:field id="month"/>
<wd:field id="day"/>
</wd:aggregate-field>
Form definition : <wd:field id="startDate" extends="date-template"> <wi:label>Start date</wi:label> </wd:field>
</wd:field id="endDate" extends="date-template"> <wi:label>End date</wi:label> </wd:field>
... or should both the form definition and template go through and transformation (XSL or STX) that "expands" the widgets ? That's a more immediate solution, but introduces new pipelines and "cocoon:" sources for the definition and template.
What do you think ?
- it allows for (maybe easier) validation rules on the split parts
Sure !
- 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 ;-))
Which confirms the previous point.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
