cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)
Date Fri, 01 Aug 2003 10:13:46 GMT
Marc Portier wrote:

> 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:field id="birthDate.year"/>
  <wi:field id="birthDate.month"/>
  <wi:field id=""/>

<wi:field id="endDate">
  <wi:field id="birthDate.year"/>
  <wi:field id="birthDate.month"/>
  <wi:field id=""/>

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"/>

Form definition :
<wd:field id="startDate" extends="date-template">
  <wi:label>Start date</wi:label>

</wd:field id="endDate" extends="date-template">
  <wi:label>End date</wi:label>

... 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message