Le 14 d�c. 04, � 03:07, David a �crit :
...don't want to have to 'manually' build a bunch of forms and form processing
and file i/o code to create these interfaces for the half dozen different
xml data structures I have....
The forms processing and file i/o code is very simple if using CForms, and it doesn't depend on the form contents.
You'll find examples in the linotype (for i/o) block and in the forms and tour blocks (for CForms stuff).
This leaves you with the actual forms: for these you'll need to create CForms models, bindings and templates, which are usually created individually.
But, at least for simple cases, these are relatively easy to generate from a common definitions file, to avoid creating three definition files for each form: I'd start with a custom "form editing template" written in XML, which contains enough information to generate the CForms model, binding and template definitions.
Here's a rough example with an imaginary syntax:
<body> <h1>This is the xyz form</h1> <form-field id="username" edit-tool="string" binding-path="/user/name" required="true"/> </body>
You can then relatively easy transform this (via XSLT) to a CForms model, a binding and a template, or invent new attributes depending on the CForms features that you need.
There's no universal solution for this in Cocoon, as it is more limited than "full-blown" CForms and the limitations that you're willing to accept depend on your application. So the best way ATM is probably to create you own "form definition" model and build on it.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
