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
it.
> 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:
cocoon.load("resource://org/apache/cocoon/woody/flow/javascript/woody.js");
function myapp() {
var mainForm = new Form("path/to/formdefinitionfile.xml");
var somePickerForm =
new Form("path/to/anotherformdefinitionfile.xml");
mainForm.show("mainform-display-pipeline", formHandler);
}
function formHandler(form) {
switch(form.getSubmitId()) {
case "goto-picker":
{
somePickerForm.show(...);
mainForm.getModel().myfield =
somePickerForm.getModel().somefield;
}
break;
}
}
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
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
