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] Update of "CocoonFormsLibraryProject" by MaxPfingsthorn
Date Tue, 14 Jun 2005 19:52:41 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

------------------------------------------------------------------------------
  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 [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 functionality should also work for form bindings and templates. This would effectively
cover all three tiers of CForms.
- 
- 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'''
  
@@ -32, +25 @@

    a. import of library files
    a. extending definitions from libraries (e.g. changing id's or adding more validators)
    a. nested inclusing/extension in libraries (libraries include and extend others)
-   a. above features also applicable for bindings instead of definitions
+   a. above features also applicable for bindings and templates instead of definitions
+   a. improve the current forms cache to exploit the library structure
   1. Documentation for developer usage of the new feature on the wiki as well as the new
Cocoon Zone ([http://cocoon.zones.apache.org/daisy/cocooninaction/4.html Daisy])
- 
- Soft Deliverables (if there is time left):
- 
-  1.#3 Rework of CForms API to Flowscript and Javaflow (Server side business logic)
-  1. Update of standard CForms XSLT sheets
-  1. Update of the current unit tests to ensure backward compatibility and to include new
features
  
  '''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], implements only the library loading part), 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.
+ 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], implements only the library loading part within an outdated CForms framework),
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.
  
- The project will start with an evaluation of the currently available very basic and partial
implementation. It will then progress to the design and coding of the missing parts. Finally,
I will throughly test and evaluate my contributions as well as CForms itself and include user
documentation. Ultimately, if there is still time left, I will dedicate more time to the 'Soft
Deliverables' mentioned above.
+ The project will start with an evaluation of the currently available very basic and partial
implementation. It will then progress to the design and coding of the missing and to-be-updated
parts. Finally, I will throughly test and evaluate my contributions as well as CForms itself
and include user documentation.
  
  '''Project Schedule'''
  

Mime
View raw message