Mailing-List: contact docs-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@cocoon.apache.org
Date: Tue, 25 Nov 2003 11:00:07 +0100
Message-Id: <200311251000.hAPA07p31493@otsrv1.iic.ugent.be>
From: stevenn@outerthought.org
To: docs@cocoon.apache.org
Subject: [WIKI-UPDATE] CocoonFormsRoadmap Tue Nov 25 11:00:07 2003

Page: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsRoadmap , version: 1 on Tue Nov 25 09:09:01 2003 by ReinhardPoetz

New page created:
+ 
+ !!!Introduction
+ Cocoon Forms seems to be the hottest topic in the Cocoon community - at least 
+ I got this impression after following the Cocoon mail-lists.
+ 
+ Thanks to the great efforts of Bruno, Sylvain, Marc, Antonio, Jeremy and some others
+ we already have a great solution. But there are still a few issues
+ open to mark Cocoon Forms as stable finally.
+ 
+ This document should help to
+ *collect all open issues preventing us from a stable release
+ *transform these open issues into a roadmap that shows our users
+  what they can expect and to get a feeling how long it will take
+  until they get a stable block
+ *get an overview who is working on which item
+ 
+ !!What can you do if you find this page?
+ *add new items to the todo list
+ *vote for a certain feature (see the voting rules below)
+ *but __don't__ add items to the roadmap section because
+  we decide on them 'together' on dev@cocoon.apache.org
+ *add your name to the __who__ paragraph in one of the items
+  (this is no legal committment but it should show others that
+  somebody else is working on a certain feature - if you don't have
+  time to do it, please add a note or simply delete your name)
+ 
+ !!Rules
+ *Everybody can add his requirements into the 'ToDo'-section of this
+  document. On cocoon-dev we discuss the roadmap and add the open
+  issues into the according category (either first stable release or 
+  later release).
+ 
+ *Everybody can add his vote to an issue of the 'ToDo'-section so that
+  we get a feeling what is required (earlier).
+ **+1 means: absolutly necessary for the first stable release
+ **+0 means: not necessary now
+ **-1 means: I don't want to see this feature being part of CocoonForms
+ 
+ 
+ !!!Cocoon Forms Roadmap
+ 
+ 
+ !!First stable release
+ TBD
+ 
+ !!Later releases
+ TBD
+ 
+ !!Rejected features
+ TBD
+ 
+ !!!ToDo's
+ 
+ !move Woody into CocoonForms block
+ (rename all packages, namespaces and namespace-prefixes)
+ 
+ who: ?\\
+ status: open\\
+ vote: +1 (RP),\\
+ 
+ ----
+ 
+ !support for multi-page forms
+ 
+ who: ?\\
+ status: open\\
+ vote: +1 (RP),\\  
+ 
+ ----
+ 
+ !general review of all XML elements
+ Is our naming of interfaces/classes/elements/attributes/ consistent? 
+ Are there better element/attribute names?
+ 
+ see [XML formats|WoodyFileFormats]
+ who: ?
+ status: open
+ vote: +1 (RP),  
+ 
+ ----
+  
+ !general review of all XML elements!
+ 
+ Is our naming consistent? Are there better element/attribute names?\\
+ see [XML formats|WoodyFileFormats]\\
+ 
+ who: ?\\
+ status: open\\
+ vote: +1 (RP),\\  
+ 
+ ----
+ 
+ !datatypes repository
+ 
+ who: ?\\
+ status: open\\
+ vote: +0.5 (RP),  \\
+ 
+ ----
+ 
+ !JXTemplate: add a CocoonForms taglib
+ 
+ who: ?\\
+ status: open
+ vote: +1 (RP),  
+ 
+ ----
+ 
+ !Multi-sources binding
+ 
+ make it possible to bind more than one source (bean, xml-document, ...)
+ at least we need a recommendation how to handle this (this could also
+ be to create one 'big' bean that contains all values
+ 
+ reported by: [Reinhard Poetz]\\
+ who: ?\\
+ status: open\\
+ vote: +1 (RP),\\
+ 
+ ----
+ 
+ !use another expression language (replace xReporter expressions)
+ 
+ evaluate other, more standard, expression engines such as Jexl and JXPath
+ and compare with the currently used xreporter-expression package.\\
+ 
+ who: ?\\
+ status: open\\
+ vote: +1 (RP),\\
+ 
+ ----
+ 
+ !widgets
+ *widget for semi-structured content
+  who:?\\
+  status: open\\
+  vote: +1 (RP)\\  
+ *tree widget\\
+  who:?\\
+  status: open \\
+  vote: +0 (RP), \\ 
+ *validation widget\\
+  validation widget: a widget that has no value of its own, but just serves 
+  to perform validation on or between other widgets (for validation rules that 
+  don't belong to a specific widget).\\
+  who:?\\
+  status: open\\
+  vote: +1 (RP),   \\
+ 
+ ----
+ 
+ !styles
+ add support for XUL, simple HTML, ...
+ 
+ who: ?\\
+ status: open\\
+ vote: +0 (RP),\\
+ 
+ ----
+ 
+ !widget interface: setValidationError
+ Add an setValidationError or addValidationError method to the Widget interface
+ 
+ who:?\\
+ status: (partly done: the field widget already has this)\\
+ vote: \\
+ 
+ ----
+  
+ !calculated fields
+ 
+ who:?\\
+ status: open\\
+ vote: +0 (RP), \\
+ 
+ ----
+  
+ !default values for fields
+ 
+ who:?\\
+ status: open\\
+ vote: +1 (RP),\\
+ 
+ ----
+ 
+ !checking validity of id's
+ (should not contain spaces or dots, or characters not allowed in request parameters)
+ 
+ who:?\\
+ status: open\\
+ vote: +1 (RP),
+ 
+ ----
+  
+ !Subforms
+ Including one form in another form\\
+ who:?\\
+ status: open \\
+ vote: +0 (RP),
+ 
+ ----
+  
+ !Utility checking form definition and form template
+ make an utility that checks that all (required) fields defined in the 
+ form definition are present in the form layout template\\
+ 
+ who:?\\
+ status: open \\
+ vote: -0.5 (RP - don't know if this is possible if we have a global datatype repository),  
+ 
+ ----
+ 
+ !Enhanced validation for selection lists
+ for fields with a selection list, it should be checked that the submitted 
+ value is effectively in the selection list (to avoid problems with people playing 
+ with request parameters). Since this could potentially be expensive (if the 
+ selection list is dynamically generated), maybe do this as a seperate validation rule.
+ 
+ who:?\\
+ status: open \\
+ vote: +0 (RP)\\
+ 
+ ----
+  
+ !AggregateField
+ adapt the AggregateField so it can aggregate the other way around as 
+ well (see [mail-list-proposal|http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105712568410208&w=2])
+ 
+ requested by: [mpo|MarcPortier]\\
+ who:?\\
+ status: open \\
+ vote: +0 (RP) \\
+ 
+ ----
+ 
+ !woody form-model - JavaScript model
+ think about transfering (part of) the woody form-model information over to the 
+ client as a javascript model that can be interpreted by a set of client-side 
+ javascript functions inside the browser\\
+ requested by: [mpo|MarcPortier]\\
+ who:?\\
+ status: open \\
+ +vote: \\
+   
+ !binding isolation woody model
+ make the 'binding' isolate the woody model from the business model 
+ --> fieldbinding should perform a clone()
+ 
+ requested by: [mpo|MarcPortier]\\
+ who:?\\
+ status: open \\
+ vote: \\
+ 
+ ----
+ 
+ !cache compiled bindings
+ 
+ who:?\\
+ status: open \\
+ vote: \\
+ 
+ ----
+ 
+ !enum convertor
+ create an "enum" base type and an "enum" convertor for types that 
+ implement the [TypesafeEnumPattern|http://developer.java.sun.com/developer/Books/shiftintojava/page1.html#replaceenums]
+ 
+ requested by: [ugo|UgoCei]\\
+ who:?\\
+ status: open  \\
+ vote: \\
+