Thanks for moving the discussion to the list.
I think its better to get more people involved in this tough issue.
See below:
> > > 1. your binding of request parameters will not allow proper chechbox
> > > populating. (remember: a not-checked will *not* be reflect by a
> > > request parameter - so selecting "false" is tricky!)
> >
> > Agreed.
> > That's why the action should do something to the JavaBean, like
resetting
> > its state before it calls bind.
> > Actually the sample FormBindingAction, should probably become a
> > GenericBindingAction, which calls an empty protected reset() and then
does
> > bind.
> > Then if someone uses forms with checkboxes, then they can extend it and
> > implement the reset() method.
> > The concept is borrowed from Struts' reset() method, which gets called
> > before the formbean is populated.
>
> Hm... doesn't sound like a good plan: look at this example
>
>
> <user>
> <name/>
> <email/>
> <committer>false</committer>
> <works-on-other-projects/>
> </user>
>
> So what will happen if we collect the data over two pages
>
> page1:
> reset
> populate "Torsten" into "user/name"
> populate "[EMAIL PROTECTED]" into "user/email"
> populate "true" into "user/committer"
>
> page2:
> reset
> populate "true" into "user/works-on-other-projects"
>
> We will get:
>
> <user>
> <name>Torsten</name>
> <email>[EMAIL PROTECTED]</email>
> <committer>false</committer>
> <works-on-other-projects>true</works-on-other-projects>
> </user>
>
>
> ...but committer should be "true"!!
>
> So the only way I see is to explicitly bind what to populate on the
> button.
>
> page1: button "next" -> populate user/name + user/email +
user/committer
> page2: button "next" -> populate user/works-on-other-projects
Typicly my Actions have a switch statement based on the button which was
pressed.
Or if using Cocoon's action convention this can be achieved with an action
set as well.
In both cases the idea is that the Action has an idea of where you are with
the wizard navigation and resets just these fields, which are necessary to
correctly populate the bean in the current step. I.e.
act(...)
{
if (request.getParameter("command").equals("page1"))
resetCommiterField
else if (request.getParameter("command").equals("page2"))
resetWorksOnOtherProjectsField
...
bindFormToBean
...
}
>
> > > 2. since validation happens inside the XSLT transformer we cannot
> > > change the flow according to the validation results :( I fear
> > > validation must happen inside an action...
> >
> > Yes, this is a tough nut to crack.
> > I'm trying to engage other people on the dev list with the discussion on
> > this very problem.
> >
> >
> > Keep your ideas flowing this way !
> >
> > If this thing makes it into scratchpad, we have an even bigger
> > responsibility to do the job right with the complex wizard.
>
> If you don't mind (give me 1-2 days) I will merge our projects and I'll
> then commit it to the scratchpad, ok?
Sounds great to me ! Thanks !
Ivelin
> --
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
