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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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
