cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)
Date Thu, 31 Jul 2003 09:59:30 GMT


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


Mime
View raw message