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 16:52:34 GMT
Marc Portier wrote:

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

Agree. But the date-with-3-fields use case if the perfect example where 
GUI decisions (using these 3 fields instead of a single input) have an 
impact on the Woody 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 understood it clearly.

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

Sure. But in my experience, the model designer and template designer are 
the same person (knowledged about the application domain), while the 
"layout designer" is a webdesigner that defines the formatting XSLs 
according to the project graphical requirements.

This is what I've seen on most projects we've done here. And for the 
current one, the customer has to be able to modify the forms (both model 
and template) without knowing html (or very roughly).

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

In my experience (again), this is the layout-designer that will take 
this decision.

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

You mean a hint that tells the transformer if children of the aggregate 
field should be propagated or not ?

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

Is this still unnatural if you consider the aggreagate field as a group 
(XMLForm has this) ?

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

That's what came to my mind at first, but the childrens need to be named 
widgets, so I think they should be kept in the widget realm. Moreover, 
considering the date example, the aggregated field is not only a 
container, but also has a value of a base type (a Date object).

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

That's why I suggest to keep this discussion on aggregated types for 
later (after all, it's peripheral), and come back on it after some real 
experiments using dynamically produced definitions and templates.

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

Actually, I already did something similar with XMLForm : an additional 
XSL in the pipeline "expands" metawidgets which represent composite 
datastructure that are often present in the application model. This 
allows a consistent and painless layout for these recurring composite 
structures, and this works perfectly with XMLForm since it doesn't have 
a model. Woody having this model, the metawidgets must be expanded in 
both the definition and in the template.

But as I said, let's experiment with XSL transformations and see 
afterwards what can be injected back into Woody's core.

> 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 think you understood it ;-)

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

[scrolling yellow text] In a galaxy far away... This is Dark Woody ;-D


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message