[WIKI-UPDATE] WoodyFileFormats Sat Aug 2 23:00:03 2003

[st...@outerthought.org]

Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyFileFormats , version: 3 on Sat Aug  2 20:45:29 2003 by SylvainWallez

+ * Binding : http://apache.org/cocoon/woody/binding/1.0
- * For the particular FormattingDateConvertor and FormattingDecimalConvertor, verbosity could be reduced by removing the {{<patterns>}} container element since the configuration doesn't contain anything else.''
+ * For the particular FormattingDateConvertor and FormattingDecimalConvertor, verbosity could be reduced by removing the {{<patterns>}} container element since the configuration doesn't contain anything else than a list of {{<pattern>}}.''
?                                                                                                                                                                                                               +++++++++++++++++++++++++++++

+ Datatypes can use an existing format defined in the format dictionary, or define inline anonymous formats. If a datatype doesn't specify a format, the default format for that type, as defined in the xconf file is used.
+ 
+ Datatypes can have validation rules that restrict the set of allowed values compared to that of the base type.
+ 
+ {{{
+ <wd:datatypes xmlns:wd="http://apache.org/cocoon/woody/definition/1.0">
+   <wd:datatype id="past-date" basetype="date">
+     <!-- inline format -->
+     <wd:format converter="formatting">
+       <pattern locale="fr_FR">dd/MM/yyyy</pattern>
+       <pattern locale="en">MM-dd-yyyy</pattern>
+     </wd:format>
+     <!-- validation rule -->
+     <wd:validation>
+       <wd:past-date>
+         <wd:failmessage>Must be in the past</wd:failmessage>
+       </wd:past-date>
+     </wd:validation>
+   </wd:datatype>
+   
+   <wd:datatype id="price" basetype="decimal">
+     <!-- reference to a format, no specific validation -->
+     <wd:format ref="price"/>
+   </wd:datatype>
+   
+   <!-- todo : selection lists -->
+ </wd:datatypes>
+ }}}
+ 
+ ''Open items :
+ * We should be able to choose between strict selection lists (enumeration) and open selection lists (an input help). This could go through an additional "open" attribute (default is false, meaning strict enumeration).
+ ''
+ 
+ !!! Form definition file
+ The form definition file defines all widgets contained in a form.
+ 
+ Fields, i.e. widgets that have a value, have a datatype, which can be a reference to a datatype defined in the datatype dictionary, or define inline an anonymous datatype.
+ 
+ Fields can have validation rules that restrict the set of allowed values compared to that of the datatype.
+ 
+ ''Note: it is theoretically possible for a field to have an inline datatype defining constraints and have its own constraints. Although this is not very desirable from a readability point of view, this won't cause any problem.''
+ 
- !!! Form definition file
+ ''Open items :
+ * The validation algorithm will check the datatype's rules before the field's one. How can then a field change the {{<failmessage>}} for a validation rule of its datatype ?
+ * Same remark for selection lists (although this seems less important at first)
+ * Can a field define its own selection list if the datatype has one ?''
+ 
+ !!! Form binding