cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Trivial Update of "CocoonFormsLibraryProject" by MaxPfingsthorn
Date Tue, 14 Jun 2005 18:28:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by MaxPfingsthorn:
http://wiki.apache.org/cocoon/CocoonFormsLibraryProject

------------------------------------------------------------------------------
  '''Synopsis'''
  
  Cocoon Forms is a, if not the most, prominent part of Apache's Cocoon framework. With CForms
(short of Cocoon Forms), it is possible to define a form independent from the display and
handling of the POST/GET data returned from the client browser. It is also possible to bind
the input/output of the form to Java Beans or XML streams. This way it is easy to generate
complex and mutable forms with server-side validation which produce XML: The core technology
used in Cocoon.
- This project focuses on making the form definitions more readable, portable, extensible,
maintainable and sharable. A rough sketch of the desired functionality is available at WhiteBoardCocoonForms.
+ This project focuses on making the form definitions more readable, portable, extensible,
maintainable and sharable. A rough sketch of the desired functionality is available at [http://wiki.apache.org/cocoon/WhiteBoardCocoonForms].
  After the completion of this project, form definition blocks (or widgets) will be able to
be defined in separate "widget library" files which can be tied in to a specific definition
easily. Also, widgets are inheritable so to override properties or add behaviour as needed
in the more specific form definitions.
+ 
+ This project might be extended to one or more of the following in case the work laid out
above is implemented in much less time than the allotted two months:
+ 
+ Wishlist items pertaining to CForms:
+  * Refactoring the CForms API exposed to Flowscript and Javaflow (from Jakarta Commons)
(by ReinhardPoetz),
+  * Refactoring the standard XSLT for CForms for better reuse (by ReinhardPoetz),
+  * An improved testing suite to ensure backwards compatibility (by ReinhardPoetz),
+  * ... and more ideas from the community
  
  '''Benefits to the Community'''
  
@@ -25, +33 @@

  
  '''Project Details'''
  
- The project will mostly be contained within the Cocoon Forms formmodel class heirachy. After
some inspection of the current code and code which already very basically implements parts
of this feature (available at [http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/ SVN
Whiteboard]), I come to the conclusion that there should be a separate component to store
library definitions which are kept in memory (maybe in a LRUMap commonly used for Last-Recently-Used
chaches) and provide definition objects of the widgets that are referenced in form definitions.
As some kind of inheritance of widgets is required, the general WidgetDefinitionBuilder heirarchy
has to be extended to allow for overriding parameters in a given definition of the same kind.
+ The project will mostly be contained within the Cocoon Forms formmodel class heirachy. After
some inspection of the current code and code which already very basically implements parts
of this feature (available at [http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/ SVN
Whiteboard]), I come to the conclusion that there should be a separate component to store
library definitions which are kept in memory (maybe in a LRUMap commonly used for Last-Recently-Used
chaches) and provide definition objects of the widgets that are referenced in form definitions.
As some kind of inheritance of widgets is required, which is still to be designed and implemented,
the general WidgetDefinitionBuilder heirarchy has to be extended to allow for overriding parameters
in a given definition of the same kind.
+ 
  
  '''Project Schedule'''
  

Mime
View raw message