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="birthDate.day"/> </wi:field>
<wi:field id="endDate"> <wi:style><date/></wi:style> <wi:field id="birthDate.year"/> <wi:field id="birthDate.month"/> <wi:field id="birthDate.day"/> </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= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
