Return-Path: 
 <cocoon-dev-return-24372-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 71244 invoked by uid 500); 16 Mar 2002 18:46:58 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 71233 invoked from network); 16 Mar 2002 18:46:58 -0000
Message-ID: <00ca01c1cd1c$09718ee0$0c91fea9@galina>
Reply-To: "Ivelin Ivanov" <ivelin@sbcglobal.net>
From: "Ivelin Ivanov" <ivelin@iname.com>
To: "Torsten Curdt" <tcurdt@dff.st>
Cc: <cocoon-dev@xml.apache.org>
References: <Pine.LNX.4.31.0203151534320.3166-100000@mogh.dff.local>
Subject: Re: Cocoon Form Handling
Date: Sat, 16 Mar 2002 12:54:43 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


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 "tcurdt@apache.org" 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>tcurdt@apache.org</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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org