Bruno Dumon <[EMAIL PROTECTED]> writes: > > 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!
Cool... > > > > 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. Hmm, not sure. Our form model is independent of the back end and how the data is produced. I think the biggest difference is that we have three components: a metadata object model (similar to half the cForms form model), the presentation template (similar to the cForms template) and a separate validation template (the other half of the cForms form model), but coupled to the template. It's a little more work to maintain but it separates out the concerns completely. > > 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. > Something our system is definitely not designed for! > * 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. This is precisely what our system is designed to do. > 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. > I have some thoughts on how you can do a generalized repository (a generalization of our generalizations). I'll have to think about whether it's anything anyone could actually use without getting lost in the generalizations and resulting abstractions... <snip/>
