On Tue, 2004-06-01 at 23:07, Hunsberger, Peter wrote: > Bruno Dumon <[EMAIL PROTECTED]> writes: > > As I've noted previously, we've got a proprietary forms system and I > don't have much experience with cForms. However, our experience may be > useful to you (feel free to disregard!).
Always appreciated! > > We allow multiple templates per form model. Basically we treat them both > as metadata and create a merged instance specific metadata model as > needed. This allows templates to customize generic form objects giving > you much more back end reusability and allowing you to exploit XSLT for > custom rendering much more easily. To do this we couple the validation > rules to the template and not to the form model, thus you avoid the > issues of having to merge the models at validation time. Our Validation > rules are a Schematron skeleton that gets converted into normal > Schematron via XSLT at validation time (via a Cocoon pipeline). > Essentially, the presentation template has a link to the validation > template. The way I see it (currently), the combination of a CForms model and template is what the template is in your system. CForms doesn't try to replace the backend. I see in fact two different uses of the form framework: * smaller applications where the required CForms forms are defined ad hoc. This is what lots of people are doing. * applications whereby all fields and screens are defined in the backend, usually a large amount of them, and usually adjustable by the customer of the application. In this case the CForms form definitions and templates can be generated dynamically based on information from the backend, and CForms then simply functions as the thing that actually handles the user interaction. For a long time I had mainly the first scenario as use case, but it just happens that (potential) customers we've been in contact with often need the second case. Due to the declarative nature of CForms (which was originally mainly to make it usable by 'non-programmers'), it is actually quite easy to generate these CForms from backend data. With typical Java form handling frameworks one would need to generate and compile Java code to do this kind of stuff. OTOH, there are also concrete plans to add widget repository functionalities to CForms itself, so that for people who directly use CForms, it will also become possible to reuse widget definitions across multiple forms. > > We do allow for widgets to be specified as mandatory at the form level, > but for those that are not mandatory, the template writer can choose to > include them as they see fit. > > Don't know if you can do any of this with cForms, but it's certainly > proved very powerful for us... > > An example for us is a Radiation therapy form. We support over 30 > possible widgets, but no single user of the form wants to see them all. > For many treatment protocols we show less than 10. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
