cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stev...@outerthought.org
Subject [WIKI-UPDATE] WoodyRefactoring CubistForms LuceneIndexTransformer Fri Apr 16 11:00:05 2004
Date Fri, 16 Apr 2004 09:00:05 GMT
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.
+ 



Mime
View raw message