cocoon-dev mailing list archives

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

Sylvain Wallez wrote:
> Marc Portier wrote:
>> Sylvain Wallez wrote:
>>> Andreas Hochsteger wrote:
>>>> Hi!

<snip />

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

hehe, I needed some time to come up with a sensible defense for 
the aggregate-existence towards myself and Bruno as well, so this 
is not a real surprise :-)

however once you get into the view that 'Woody needs to know the 
most details from both sides' this aggregatefield isn't that big 
of hack IMO

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

agree, specially on the no-yes-no grey area about this :-)

<snip me explaining the 'imposed-granularity'-theory for holding 
onto the aggregate-field/>

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

maybe that feeling has more to do with the fact that the basic 
woody-model building block is called WIDGET, and not something 
more decoupled from its visual representation on the (HTML) form? 
  Something like 'INFORMATION-NODE' or even 'SUBMIT-ARGUMENT' (I 
don't like nor propose these, but I hope it helps you understand 
how I look at them as they live in the woody-model-definition)

as explained my feeling is that woody's model should be as 
decoupled from the 'template' as it is from the 'backend-model'

(note: the above is the conceptual view I have, it does not come 
back on me supporting your effort into defining a sensible mix of 
the definition/config files to make specific usage patterns 
easier fit onto using woody in real life)

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

I think the main thing I wanted to say was about the 
'model-designer' role: he is the one that defines which 
http-request parameters can be sent to the form.

The template-designer will need to live by the rules he set.

Using the aggregateField in the model will leave some option to 
the template-designer to actually choose for a form-layout that 
is to ask/submit either the aggregated or the split-part params.

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

I think the form-model-designer is the one that defines the 
details of the HTTP-API (which request-params can be sent) - not 
the details of the form-layout

the latter is I'm afraid the role of the template-designer (who 
might cooperate with a nifty client-side-javascript designer but 
that is a different story)

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

How the defined HTTP-API-request params are mapped onto actual 
(HTML) form layout (and granularity in the case of the 
aggregate-field) is up to the template-designer

the issue of consistency between the different layouts is up to 
the template-designer to tackle (but we could help him of course, 
as you are proposing below?)

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

hm, would like it more if the template transformer would be able 
to make the decission that was handed to him by the template-hint 
  handed in the template file...

this would leave the xslt sheet following unchanged (which is not 
a goal per se, but having nested wi:field feals unnatural)

this probably would ask for the styling decission to be added to 
the wt:field as an attribute.

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

your classification is correct, but I don't think these types 
need to be assigned to the form-model 'explicitly'

this knowledge comes implicitly from how the template or binding 
are "using" this form-model.. in fact their usage my change over 
time without the need to change the model?

> 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"/>
> </wd:aggregate-field>

yep, like it

since this is in the form-model realm I can't help thinking about 
these as quite close to composite-datatypes?

(only) difference being that these introduce additional 
request-params acceptable...

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

see above for questioning if @extends could be just @basetype

looking at it as composed datatypes might be allowing us to 
logically jot down the validation rules in there as well?

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

I like dedicated transformers, but sometimes using XSLT can more 
easily provide a protoype

> What do you think ?

if what I said above makes sense, and if I heard the pain you 
want to relieve then we would still need some 
style-layouting-catalogue that declares a consistent styling tied 
to the introduced consistency of datatyping?

assuming we are near to having a template-and-definition mixing 
declaration, I would think that the same kind of mix could exist 
for the catalogues?

sorry upfront if I overlooked the crux of your posting, coming at 
the end I think I made the synopsis of both our views but that 
might be lots of wishful thinking

I'll be glad to take another look through your telescope if you 
let me ;-)

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message