[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    RE: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)
From:       "Hunsberger, Peter" <Peter.Hunsberger () stjude ! org>
Date:       2003-07-31 15:15:34
[Download RAW message or body]

Sylvain Wallez <sylvain.wallez@anyware-tech.com> writes:

> 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.

I share your concern.  See the reply I sent earlier on this:  you really
want to separate presentation and aggregation completely from the form
model itself.  That's essentially reinventing a template language (on
top of a form language).  Yuck, but how else can you do it?



[prev in list] [next in list] [prev in thread] [next in thread]