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 == 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?
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/
mpo@outerthought.org mpo@apache.org