Reinhard Poetz wrote:
I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms and I liked what I saw.
This document defines reusable macro libraries. I'm sure this is useful for some usecases (e.g. editors) but I have a simpler one that goes into the direction of reusable form definitions.
In many of my forms date widgets are used: birthdate, start date, end date, ... Definining those widgets is nearly always the same, except the label. IMO it would make sense not only to have reusable macro libraries but also reusable widget libraries (renamed fd:macros to fd:library):
<snip/>
<!-- reusable widgets -->
<fd:field name="project-date">
<fd:datatype base="date">
<fd:convertor>
<fd:patterns>
<fd:pattern>dd/MM/yyyy</fd:pattern>
</fd:patterns>
</fd:convertor>
</fd:datatype>
</fd:field>
The main problem here IMO is that view and model concerns are mixed up. If we factor out the convertion part to an own step as discussed in http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2 and the rest of that thread, there is not that much left to reuse.
Syntax:
<fd:import prefix="..." uri="..."/>
Example:
<fd:import prefix="my-macros" uri="cocoon:/custom-fd-macros.xml"/>
<fd:field name="birthdate" extends="my-macros:project-date">
<fd:label>birthdate</fd:label>
</fd:field>
Ok, here we see that it was the view aspect, (i.e. the label) of the date widget that wasn't reusable. That is quite common in my experience and one of the reasons why it is a good idea to separate model and view as models tend to be much more reusable than views.
So instead we could have a date model definition:
<fd:field name="date">
<fd:datatype base="date"/>
</fd:field>The date conversion pattern "dd/MM/yyyy" is put in a catalog with interanationalized date, number etc patterns that are used for all data type formating purposes in Cocoon, and you probably don't have to write anything at all as we can have standard conversion patterns in the distro.
Then in the template you write:
<ft:widget name="date"> <ft:label>birthday</ft:label> </ft:widget>
By placing labels, hints etc in the template (view) instead of in the widget definition you get rid of the view info from the "model" and by improving SoC it becomes easier for people that are web designers rather than programmers to work with on the view aspect of the application.
--- o0o ---
I still think that "macros" can be usable for reusable "model definitions" but IMO the problem that you describe is a symptom of model/view mixup in widget definitions, and we should start to do something about that.
WDYT?
/Daniel
