cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Whiteboard Forms - Reusable form definitions (imports)
Date Tue, 08 Mar 2005 10:31:16 GMT
Daniel Fagerstrom wrote:
> 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.


hmmm, what about this: In a former project (not done with cForms) we had many 
places with order numbers, customer numbers, email adresses, credit-card-numbers 
and many other repeating domain specific field types.

In cForms you always have to write

<fd:field id="order-number">
   <fd:label>order number</fd:label>
   <fd:datatype base="string"/>
   <fd:validation>
      ...
   </fd:validation>
</fd:field>

or the creditcard field definition would be a more verbose example (think of the 
agrregation/splitting part, validation, ...). The problem is not verbosity 
(sooner or later we will use GUIs to work on cForms definitions) but 
consistency. If for some reason any free mailer e-mail adresses shold be valid 
(hotmail, yahoo, gmx, ...) I only want to change it at a *single* place.

-- 
Reinhard Pötz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message