Hi Ed
Thanks for an answer. The problem with your idea is:
IF validation fails i can not forward to previous JSP!
I need to forward to previous action to prepare me a view - retireve
something from DB and put it in <html:select>.
I have the same idea to put form.setPage(pageNo) as first thing in each
action. Moreover if i disable autovalidation
i do not have to make those tricks to decrement page in validate if errors
are found.

2006/5/6, Ed Griebel <[EMAIL PROTECTED]>:

Hi Jakub-

I'm not sure if I fully understand your pageflow, but here goes. I
would turn off automatic validation in struts_config.xml. In each
action, one of the first things I would do is call
form.setPage(pageNo) and then call form.validate(...), and if there
are any errors I'd return an ActionForward corresponding to the
previous JSP. I have an app that is very similar to this but I use a
DispatchAction and set things as described above and it works well.

As to overriding the page variable counter, it's an interesting idea,
but you may run into a problem so you'll have to trap it from going
below zero, for instance if they keep failing validation on the first
screen. One way to find out for sure is to try it out and see how it
goes!

-ed

On 5/6/06, Jakub Milkiewicz <[EMAIL PROTECTED]> wrote:
> Hi
> I have a wizzard application with 5 screens. All user inputs are
collected
> in one bean, which is named: viewBean and is stored in HTTP session.
> So each action has the same formBean - viewBean.
> I use commons-validator and viewBean properties to validate are present
in
> validation.xml with page attributes.
> ViewBean extends ValidatorForm and it's validation occurs automatically
- i
> have validation set to true for all ACTIONS.
> The structure of my app is:
> Populate view  -> jsp ->populate view ->jsp ->populate view -> jsp ...
> Population of view happens in ACTION class and can consists of
retrieving
> some data from DB, sets these data in HTTP request.
> After population process i forward to appropriate jsp to give user a
chance
> to fill the form and to present population process results as for
example
> options in <html:select>.
> If form is correct i go to another action which populate view for a next
> screen (jsp).
> If form is not filled correctly i need to show it again, but i can not
> forward to jsp - i need to forward to action that prepares the form -
that's
> why i have my input parameter of <action> tag set to action which
populate
> the view - previous action.
> I have a problem with page attribute. Please take a look at the sample
of
> processing in my app:
> ACTION1 -> JSP1 ->ACTION2 -> JSP2  ->Action3 ->JSP3 ...
> Let's assume that user submits form in JSP2 to action3. After ActionForm
> bean population, page property is set to 2. Next, validation fails in
> Action3 and input parameter of <action3> forwards user to ACTION2.
> Before execute method in Action2 is invoked, ActionForm (viewBean)
> validation occurs. The page attribute is still set to 2 ! and
> commons-validator tries to validate properties that has page attribute
set
> to 2.Obviously validation fails and control is forwarded to Action1.
Action1
> also has validation set to true and validation of ActionForm occurs
again
> with page =2.
> Validation fails and control is forwarded to ...
> Does anyone have any idea to solve the problem.
> My idea is to not to use hidden page parameter in each jsp action but
set
> page property of viewBean in each Action: for ACTION2 sets it to 2,  for
> Action3 sets it to 3 ...
> and to override validate method in viewBean:
>
> public ActionErrors validate(
>         ActionMapping mapping,
>         HttpServletRequest request) {
>         ActionErrors errors = super.validate(mapping,request);
>         if(errors != null && errors.size() > 0 )
>                page--;
>         return errors;
> }
>
> Maybe someone knows more elegant solution, or maybe architecture of my
app
> isn't valid.
>
>

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


Reply via email to