Interesting discussion since I'm currently looking for some design patterns
for this.
The first thing I bumped in, was the Scarab approach where there are
optional parameter that can be set for an action such as nextTemplate and
cancelTemplate.
Jon could give much more info about this.
I was also looking on where to store the data for the wizard...is the
session more appropriate for this or should we chain the context and pass
the data from context to context between templates ? Assuming you have an
error during your wizard transaction that could not be handled, you could
still have the objects in session in a transitional state. right ? When are
you supposed to clean up the mess if you did not commit your object ? handle
error cases via removing the object from the session in each 'wizard' screen
?
Now subsidiary question. Assuming the 'wizard' can be used in several places
in your workflow. How do you handle the 'end of wizard' ? Logically you
should go back to where you started your wizard, so you should provide your
wizard with your starting point as well.
--
St�phane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my
company.
> -----Original Message-----
> From: Leon Messerschmidt [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 02, 2001 9:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Anyone want an Action Stack?
>
>
> JUST ANOTHER OPINION
>
> I recently had a real world example where I needed queuing of actions.
> Basically I did a "wizard" type interface that goes through a
> hand full of
> forms and at the end do a database update. I can't do
> anything before I
> didn't collect all the data. So I store the data for each
> form in a session
> variable (a hidden form field for a uid solved the multi
> browser instance
> problem).
>
> When the last form is submitted its data need to be stored in
> the memory
> model and then the database update needs to be done. At the
> moment I have
> an action that duplicates the "store in session" action and
> then I do the
> database update. I think it will be cleaner to be able to
> string the memory
> store and db update actions in the template. At least I
> don't need to worry
> about updating the session variable in the db update action.
>
> If anyone has a better way of doing this I'm will be paying
> attention! At
> the moment I'm +1 for chaining actions.
>
> ~ Leon
>
>
> ----- Original Message -----
> From: "Jon Stevens" <[EMAIL PROTECTED]>
> To: "turbine-dev" <[EMAIL PROTECTED]>
> Sent: Thursday, August 02, 2001 7:39 AM
> Subject: Re: Anyone want an Action Stack?
>
>
> > on 8/1/01 10:16 PM, "Mike Haberman" <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Is anyone interested in an action stack/queue? I have it
> working in
> 3.0.
> > > on the template side you do:
> > >
> > > $link.pushAction("a1").pushAction("a2").addQueryInfo(....
> > >
> > > then in the pipline
> > >
> > > list = data.getActionQueue()
> > > for each item in list, execute it
> > >
> > >
> > > We could deprecate setAction() in favor of pushAction or
> enqueueAction.
> > > I know jason is still working on the pipeline stuff and
> has asked to
> hold
> > > off on commits, so I haven't committed it yet. But I can
> if anyone else
> > > might find it useful, let me know.
> > >
> > > mike
> >
> > JUST MY OPINION
> >
> > I still think that this is a bad design idea since what you
> will end up
> with
> > is only executing multiple doPerform() methods. You are
> also not promised
> > any order of execution since the browser may encode the
> variables in any
> > order and the servlet container/httpd may decode them in any order.
> >
> > I'm also not really sure how that is any better than
> encoding the business
> > logic into the BO's and then referencing them in the
> Actions appropriate
> > methods mapped with ActionEvents.
> >
> > In fact, I claim that it is more confusing and that the
> encoding of this
> > business logic (ie: what to execute and in what order) does
> not belong in
> > the templates.
> >
> > I don't say this very often, but I'm also -1 on including
> this in Turbine
> > proper. I don't feel that it belongs and encourages bad design of
> > applications. I'm also -1 on deprecating setAction().
> >
> > $0.00
> >
> > -jon
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
