cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25301] New: - Subforms
Date Mon, 08 Dec 2003 11:47:21 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25301>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25301

Subforms

           Summary: Subforms
           Product: Cocoon 2
           Version: Current CVS 2.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: CocoonForms
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: reinhard@apache.org


There is a discussion happening on the user list about how to
handle subforms, such as to paginate a form or to present
different mixes of widgets for different views (for example,
user versus helpdesk views).

The desire is to create one larger form definition and several
smaller form templates, each including only a subset of the
form's widgets.  The discussion has focused on how to identify
which widgets to read from the request, but other issues need
to be addressed as well.

A subform may require not only to include just a subset of the
form's widgets, but it may also require that only a subset of
the form's validation rules be enforced, and it may need to
supply a set of subform-specific validation rules.

For a large form composed of a series of time-consuming subforms
(such as for a skills and career assessment survey) there may be
a need for subforms to have their own bindings.  This would make
it easy to save entries to a temporary store as each part of the
form is completed, which would allow the user to finish the form
long after the session has expired, while still only posting the
completely validated form to the final store, bean, or xml file.

This is just a preliminary idea (a "Raw Thought") which may not
work out, but if the new union widget used an external
discriminant as described in my last "[Woody patch]..." email,
a form could be split up into subforms via unions. This already
provides server side (read as "secure") control over which widgets
are read from the request.  The same technique can be used in the
form template and in the binding to allow for subforms without
increasing the number of files to manage per form.  With a few
tweaks to the union implementation I believe we can easily support
the special validation and binding needs of subforms.

Note that this idea is intended as a suplement to the ideas others
have already presented on the user list, not as a replacement.
We have a diverse set of needs which require a diverse set of
solutions.
original posting: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106965619705596&w=2

Mime
View raw message