cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: Woody complex multipaged form
Date Thu, 31 Jul 2003 16:58:33 GMT
On Thu, 2003-07-31 at 17:00, Leszek Gawron wrote:
<snip use case/>
>                              * GOAL *
>                              ********
> I'd like to achieve the same/similar functionality with Woody without too much
> effort. 
> So first: 
> 1. Can I implement a widget that is not a standard one (a customer/product
> picker, date picker)?

yes you can, but I don't see why it's needed here. The only thing you
need is a combination of the 'outputfield' widget (being discussed but
not yet implemented) combined with the button widget.

> 2. Can I render it my way without rewriting the whole woody stylesheet? (I
> think not).

Just create a new XSL, import the woody.xsl, and add a template to
render your new widget.

> Big question now: 
> 3. Some users hate popup windows (me too). So I'd like to migrate to flow
> based approach and after customer picker button is pressed a query page is
> opened but IN THE SAME WINDOW. After picking a customer the flow goes back to
> main form. As far as I understand Woody builds it's model basing on request
> parameters (I do not get the whole binding concept right now so please correct
> me).

The binding is a completely optional feature of Woody. If you don't want
to load/store data to/from beans or XML documents, then you don't need

>  How can I store the main form data until flow gets back to it?

Just keep a reference to the form. All data is stored in the form.

The current flowscript integration is somewhat centered around one-form
handling. You'll need to write your own entrypoint instead of relying on
the 'woody' function.

I have never tried this, but this should be the basic outline:


function myapp() {
  var mainForm = new Form("path/to/formdefinitionfile.xml");
  var somePickerForm =
        new Form("path/to/anotherformdefinitionfile.xml");"mainform-display-pipeline", formHandler);

function formHandler(form) {
    switch(form.getSubmitId()) {
    case "goto-picker":
            mainForm.getModel().myfield =

The above code assumes that your button to navigate to the picker has
its action-command set to 'goto-picker'.

The myapp function is the one to call from the sitemap.

>  Let me
> remind you that the purpose of this whole thing is to write a bunch of reports
> so I really do not want to write a bean for each report I implement.

Woody doesn't require you to write a bean, all the forms data is stored
in its own form object model.

> A nice approach would be : 
> 1. Display a report form and allow user to edit data.
> 2. When a picker is pressed the whole form is stored (with no bean and stuff -
> just the whole form) somewhere in the session context under "form_name"

see above, you don't need to store it in the session, it can simply be
stored in a variable in your flowscript. Actually, using the session
limits you to one interaction with the user, since there's only one
session per user, while you can have many flow-instances.

> 3. Picker is displayed
> 4. If picker is submitted - some of picker model data is rewritten to a main
> model
> 5. Main report is displayed again.

Hope this helps,


Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message