Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyRefactoring , version: 4 on Thu Apr 16 08:12:54 2004 by MarcPortier
+ * [CubistForms] on the roles and responsibilities surrounding 'cforms' Page: http://wiki.cocoondev.org/Wiki.jsp?page=CubistForms , version: 2 on Thu Apr 16 08:31:44 2004 by MarcPortier + + !Form Definition Designer (i.e. the one on the 'cubist' spot, looking at it from all viewpoints, needing to supporting hooks to enable the needs of the others.) He does seem to have an own agenda for that: + * definition of the HTTP-interface + ** names and 'styles' of request-parameters supported on this form + * easy management through definition reuse and definition repositories + * specifying datatyping and validation + * local event-handling (with no effects outside the form scope) + * providing hooks to the processing (actions, submit with or without validation,...) + * extensibility through custom widgets (probably not), datatypes and convertors. + + + + - *Do all widget types have corresponding bindings and templates? + *Do all widget types have corresponding bindings and templates? (mpo: considering this thread [http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108194795730710&w=2] we should find matching bindings not for each widget, but for each 'value-setting-type' of widget. - **Even if we use a custom class to implement BooleanField's, why do we expose this in the XML definitions? + **Even if we use a custom class to implement BooleanField's, why do we expose this in the XML definitions? (mpo: the reason is that the request-parameters are different, I like the fact that the form-definition editor is in control of the HTTP-interface of his form, after all cforms can be used without flow but even without the forms generator or transformer. Controlling this technical interface is essential IMHO) + ** mpo: on this integrated syntax I somewhat have the same reflex as on the 'booleanfield' since multivalue and repeater lead to different request-parameter handling (x=1&x=2 versus x.1.a=i&x.2.a=j) I would welcome explicit split syntax in the definition file. But the essence of the above still holds: 'allowing repetitive values' seems to be an aspect of widgets that we could abstract out. See also discussion here: [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108209653422163&w=2] Page: http://wiki.cocoondev.org/Wiki.jsp?page=LuceneIndexTransformer , version: 24 on Thu Apr 16 08:43:40 2004 by JeroenReijn + + __Note to users of Redhat Linux:__ if you get the following error: (Empty StackException) while creating the index with the LuceneIndexTransformer try to alter your merge-factor to a lower value (default should be 10). Look at the [Lucene documentation|http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/index/IndexWriter.html#mergeFactor] for more information. +
