To prevent repopulation of an ActionForm's properties, you just need to provide a property that observes that status of another property that indicates whether the form is readonly or not. So, instead of just doing

this.property = property

you have

if (mutable) this.property = property

Or do something more sophisticated, like have it look at the page number and then decide whether to set itself or not.

Though, IMHO, the behavior for a step is so complicated that you want to put it in its own action, it should probably be outside of Struts all together, and part of the business logic layer.

(This is why chaining is frowned upon. It's a red flag that indicates business logic is creeping into your Action classes. When the business logic is sufficiently fine-grained, you should just be able to whatever you need to do from whatever Action you happen to be in. As work progresses on Commons Chain, I think this will provide a solution many people will prefer to chaining Struts Action).

I haven't had a chance to abstract it into a standard class, but here's a wizard Action that I'm working with now. It submits back to the same class, but uses a dispatch action so that if a step needs more behavior it can be encapsulated that way.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/apps/cpu/us_ok_deq_wqdata/cpu/WizardAction.java

The steps are laid out as ActionForwards to the instant ActionMapping, making it very easy to rewrite.

-Ted.

Erez Efrati wrote:
I read the HowTo write a wizard on the Struts web-site but I wasn't
really happy with the solution, and I am looking for a better one. I
came up with another way and I would appreciate your comments.


The design consists of: - The 'form' is a session scope form
- WizardAction class (a DispatchAction based) with following methods:
* init () - starting the wizard and redirect to the first page
* finish () - (or save()) finish the wizard and save the
information in the form using some business logic
delegate.

- Each Page or step in the wizard is a separate Action class, extending
a WizrardBaseAction (a DispatchAction based) which contains some
shared methods.


For example: Page1Action extends WizardBaseAction {

                        // initializes the page (done only on first
encounter)
                        ActionForward init (mapping,...) throws
Exception;
                        ActionForward back (mapping,...) throws
Exception;
                        ActionForward next (mapping,...) throws
Exception;                              ActionForward finish
(mapping,...) throws Exception;
        }               

- Each page/step has a separate action-mapping item in the configuration
with local forwards for : 'back' (if not the first page), 'next',
'finish' (if allowed from that page).

I apologize for not sketching the whole idea down to the last bit but I
hope you get the picture.


Only problem is that this design touches the question of chaining
actions verses forward redirection (not just dispatching).


For example the Page1Action.next() does the following:
        1. validate the page
        2. perform whatever processing required
        3. return the next action to forward to (redirect or chain with
all     its illness..)

In my opinion (humble one of course :) having such a separation keeping
each step in its own class is better and clearer design than having them
all in the same Action class.


Isn't there a way to prevent the reset + pre-population of the form done
while chaining actions? Furthermore, is it so bad to redirect between
actions?


Thanks in advance,
Erez










---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.

"Get Ready, We're Moving Out!!" - <http://www.clark04.com>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to