struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhou" <j...@netspread.com>
Subject Re: dificult problem, preventing population (repost)
Date Thu, 17 Jul 2003 05:16:12 GMT

----- Original Message ----- 
From: "Rob" <bss@insightoutsight.com.au>
To: <struts-user@jakarta.apache.org>
Sent: Wednesday, July 16, 2003 6:57 PM
Subject: dificult problem, preventing population (repost)


> I have the following scenario occuring.
> 
> I have a form with several fields on it (the fields are sourced to a 
> collection in an
> ActionForm). I have a button that allows the removal of fields from the 
> form (items
> from the collection). If a user removes a field from the form and then 
> double
> submits/clicks back and reloads then an exception is thrown from 
> BeanUtils.populate()
> because it attempts to take details from the (now removed field) and 
> populate it into
> the object that is stored in the position it was located in the 
> collection.  Obviously
> since the collection is now smaller this results in an 
> IndexOutOfBoundsException.
> 
> Is there any way to examine the transaction token from the form prior to 
> the form
> bean being populated and then avoid population of the form bean if the 
> token is not
> valid?

There are three steps involved when using transaction token:
1) Setting token;
2) Checking token;
3) Resetting token;

It looks right if we could perform the second step in a subclass of
the RequestProcessor so that the token is checked before form
bean population. But where do we put the first step and the
third step? If we put them in an action class, then how does
the derived request processor know when it should check
the token? If we put them all in the derived request processor,
that is not correct either, because they are business logics not
applicable to every action mappings.

The real *bad* guy is the browser's Back button your users
are using. The browser's tool bar and address bar are
intended to help load document oriented resources. They
are useless for application oriented resources in our
concepts. One good practice I saw is to turn off the
tool bar and address bar. It gives you the look and feel 
of *real* applications. Of course, you must provide navigation
buttons for your applications.

Sometimes, business people would say they *want* the
tool bar or address bar (actually they do not know what
really they want in many times :-) In such case, you have
to find a way to disable the Back button. If you try the
JavaScript location.replace() in the second page, it will
forget the past - no back any more.

As you see, it is not easy to get a *correct* solution and
my suggestion may not be applicable to your case. But I
am interested in any further thoughts.


> 
> Help with this problem would be greatly appreciated.
> 
> Rob
> 

Jing
Netspread Carrier
http://www.netspread.com

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message