Hello, I have something running exactly what Timur is looking for. But I had to modify and compile Woody (and Cocoon) for it. I did port it to CForms a few weeks ago. I have added a long text at the end of this email about how it is working. It uses a custom Form and Bindingmanager, so I had to introduce an Avalon/Excalibur selector for selecting the Form- and Bindingmanager. So it is not a simple hack. The binding is bean-only at the moment. Question to Joerg: is there any plan/idea about how this should be implemented in the "official" way?
Hugo Burm > -----Original Message----- > From: Joerg Heinicke [mailto:[EMAIL PROTECTED] > Sent: Friday, June 04, 2004 2:32 PM > To: [EMAIL PROTECTED] > Subject: Re: [Woody] the easiest way of creating forms > > > On 04.06.2004 12:36, Timur Izhbulatov wrote: > > > Hi! > > I have to create a set of forms containing identical > widgets. It would > > be very useful to put these widgets in a separate file and somehow > > include them in the declaration of the form. How could I do that? > > Unfortunately the widget repository is not implemented yet. I helped > myself by using standard XML entities to avoid massive copy & paste. > > Joerg > ========================================================= === current Woody A simple Woody flowscript example consists of 1) a model: a list of widgets that define the form. 2) a binding: defining the relation between the model and the bean with userdata. 3) a view (called a template in the Woody examples. I will call it a view because the word template is used in a different context. the view defines how the form is shown on the screen. === my changes: 1) A model is defined by a list of model templates. These are ordinary Woody models which will act as subform models. They are cached by the Cocoon transient cache. The model is defined by a model definition file: <?xml version="1.0" encoding="ISO-8859-1"?> <model id="modellist-1" file="forms/model-list.xml"> <wd:form xmlns:wd="http://apache.org/cocoon/woody/definition/1.0";> <wd:widgets/> </wd:form> </model> This file is an empty but valid Woody model definition file contained within the <model> element. This model element has as one of its attributes a file (model-list.xml) that defines the model templates. This file looks like this: <?xml version="1.0" encoding="ISO-8859-1"?> <list> <item name="forms/test_model.xml"/> <item name="forms/test2_model.xml"/> </list> The templates are normal Woody form models. When the model definition file is parsed by the custom Woody Formmanager, and the templates are not yet stored in the cache, this list of templates is parsed and stored in the cache. The custom Woody Formmanager then returns a valid but empty FormDefinition and Form. 2) A binding is defined by a list of binding templates. These are ordinary Woody bindings which will act as subform bindings. They are cached by the Cocoon transient cache. The binding is defined by a binding definition file: <?xml version="1.0"?> <model id="bindinglist-1" file="forms/binding-list.xml"> <wb:context xmlns:wb="http://apache.org/cocoon/woody/binding/1.0"; path="/" /> </model> This file is an empty but valid Woody binding definition file contained within the <model> element. This model element has as one of its attributes a file (binding-list.xml) that defines the binding templates. This file looks like this: <?xml version="1.0" encoding="ISO-8859-1"?> <list> <item name="forms/test_binding.xml"/> <item name="forms/test2_binding.xml"/> </list> The templates are normal Woody form bindings. When the binding definition file is parsed by the custom Woody Bindingmanager, and the templates are not yet stored in the cache, this list of templates is parsed and stored in the cache. The custom Woody Bindingmanager returns a valid but empty JXPathContextBinding. ==== So a lot of work done by the default Woody Form- and Bindingmanager is postponed byt the custom managers. Time for the real beef. ==== 3) A view is defined by a list of view templates. These are ordinary Woody views which will act as subform views. They are cached by the Cocoon transient cache. The view is defined by a view definition file: <?xml version="1.0" encoding="ISO-8859-1"?> <model id="viewlist-1" file="forms/view-list.xml"> <page xmlns:wt="http://apache.org/cocoon/woody/template/1.0"; xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";> <title>Templates</title> <content> <wt:form-template action="#{$continuation/id}.continue" method="POST"> <instance id="0"/> <instance id="1"/> <instance id="0"/> <input type="submit"/> </wt:form-template> </content> </page> </model> This file is an almost empty but valid Woody view definition file contained within the <model> element. This file obviously will try to put subform 0, subform 1, and once again subform 0 on the screen. The model element has as one of its attributes a file (view-list.xml) that defines the view templates. This file looks like this: <?xml version="1.0" encoding="ISO-8859-1"?> <list> <item name="forms/test_view.xml"/> <item name="forms/test2_view.xml"/> </list> The view templates are normal Woody templates. 4) Time to put something on the screen. The custom WoodyGenerator starts to parse the view definition file. When it finds an <instance id="n">, it includes the n-th view template into the SAX stream. But before doing this, it adds the n-th model template to the form model definition, and the n-th binding template to the binding definition, and it loads the data into the form via the added bindings. So the whole model, binding, and view is build "on the fly" by the generator, just before sending it into the SAX pipeline. The whole thing depends on prefixing the id's and a few other attributes with a unique id prefix. 5) It is working for me, but is a quick hack. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
