Sylvain Wallez <[EMAIL PROTECTED]> 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?
