cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)
Date Thu, 31 Jul 2003 15:15:34 GMT
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?



Mime
View raw message