ActionRedirect, saveMessages and Referer: keep messages in the session

[Michael Jouravlev <jm...@gmail.com>]

The proposal
------------
Enhance ActionRedirect, saveMessages and RequestProcessor, so messages
would not be removed from the session immediately after redirect.
Allow messages to stay in the session, so page could be reloaded
alongside with messages for better usability.

The background
--------------
saveMessages can queue to the session and RequestProcessor removes
messages after they have been shown. But would not it be better, if
the result form, which has been redirected to, could be reloaded, and
the messages would be preserved? If I understand correctly, current
implementation of saving messages to the session does not allow that.

I would like to suggest two solutions. One works in 100% cases, but
does not look nice, another looks nice, but can be broken by firewalls
or users too much concerned about their privacy.

The problem
-----------
Error messages should be retained when page is reloaded, but should be
cleared when page is navigated from outside. Why? Say, we have item
list. We click on "edit" button to edit one item. We enter wrong value
and submit item. Error is generated and item page is redisplayed with
error message. We want to be able to refresh this page and still see
the message.

But if we click Back and then select the same item from the list
(clicking forward instead of selecting the same item works like
refresh, so it is a different and sad story), we would probably want
to see the item with original data and without message.

So, we need to distinguish between:
1. page is shown after being redirected from submit
2. page is reloaded
3. page is navigated from outside

The (1) should sound like "after being redirected from action which
generates messages" but messages are usually generated on submit.

We would want the same behaviour in 1 and 2, but application cannot
distinguish between 2 and 3.

First approach: add parameter to redirected URL
-----------------------------------------------
In this case, after submit action, we add the parameter which will
tell view action that this page is a result of submit, and error
messages should not be cleaned. Refreshing this page is ok too, since
it preserves URL.

Simple. But not nice, because if a user made one or several errors and
wants to return to the list, he would have to click Back _twice_,
because browser accumulates pages in the history according to their
location, and location of redirected page is different, it has
additional parameter. (This history thing works great in MSIE and
Mozilla/Firefox, and does not work in Opera, but with 2% market share
I would not bother. Also, Opera users just love when their beloved
browser caches everything).

Second approach: use Referer header
-----------------------------------
This may not work, if a user or firewall decided to strip Referer
header in puny attempt to increase privacy. Is this my fault? Should
not they be punished for messing with core HTTP features? I think they
should ;) Anyway, this solution is cleaner.

Say, you have page which was generated by editItem.do. You submit it
either to storeItem.do, and it redirects back to editItem.do to show
error, or you postback it to editItem.do, which processes input and
shows page again:

a) GET editItem.do (show page) --> POST storeItem.do (save) --> GET
editItem.do (show page)
b) GET editItem.do (show page) --> POSTback editItem.do (save) --> GET
editItem.do (show page)

In both cases, when the page is shown again, it has editItem.do as a
referer, storeItem and other intermediate locations are not used for
Referer header.

The Rule
-----------
So, if page URL is the same as referer URL, then this is a refresh
after submit, and messages should not be cleared. If referer is
different, then messages should be cleared if any, because the page is
loaded from outside.

The downside
------------
Messages would pile up in the session. So what? The usability is more
important, is not it? Also, messages are saved per action/session, not
per action/session/item, so it is not that bad.

Michael.

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

Re: ActionRedirect, saveMessages and Referer: keep messages in the session

[Joe Germuska <Jo...@Germuska.com>]

>saveMessages() can be overloaded to take couple more parameters, like
>"keep on refresh" and "use referer header" (or this can be put in
>config file, but in this case actionMapping would need to be changed,
>that you are presumably against of.)

Not necessarily against extending ActionMapping, although in Struts 
1.3 the ability now to set arbitrary config properties on an instance 
of ActionConfig may eliminate the need to extend it in favor of using 
standard agreed upon property names instead.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: ActionRedirect, saveMessages and Referer: keep messages in the session

[Michael Jouravlev <jm...@gmail.com>]

On 4/27/05, Joe Germuska <Jo...@germuska.com> wrote:
> >I understand your point, but I just hate when they say: "we won't
> >implement this because it affects scalability, speed, cost of
> >equipment, etc". Isn't the whole thing for the end user after all???
> 
> speed and scalability, at least, can result in impacts to the user
> experience as well.

What do you think, how many users of Win98 would prefer to install
Win3.1 on their Pentium4 to increase speed? (obviously not for
scalability purposes). How many people would replace their V8 SUVs for
small four-bangers without A/C or power windows, even if the latter go
faster and turn better? Just venting out ;-)

> Is there any way to conceive an implementation strategy here which is
> a choice instead of a required fundamental change to Struts?

Of course. I don't like when I install a new version, and it breaks
old code. These enhancements were they approved, will be addons to
current functionality, not a replacement. So if someone did not know
about it, he would not break anything.

saveMessages() can be overloaded to take couple more parameters, like
"keep on refresh" and "use referer header" (or this can be put in
config file, but in this case actionMapping would need to be changed,
that you are presumably against of.)

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

Re: ActionRedirect, saveMessages and Referer: keep messages in the session

[Joe Germuska <Jo...@Germuska.com>]

>I understand your point, but I just hate when they say: "we won't
>implement this because it affects scalability, speed, cost of
>equipment, etc". Isn't the whole thing for the end user after all???

speed and scalability, at least, can result in impacts to the user 
experience as well.

>Also, I've heard that certain session replication products (I don't
>want to make an ad for Cameron) are quite good, and handle session of
>several megs easily.
>
>Also, it would be only one set of messages per action/session, not per
>item! When the same user opens another item with the same action, old
>messages would be cleared. So, the number of message blocks is limited
>and can be calculated. So messages will not pile up uncontrollably.

Is there any way to conceive an implementation strategy here which is 
a choice instead of a required fundamental change to Struts?  I don't 
have any great ideas immediately, and these are some core classes, 
but I think Frank's concerns are important enough that any change 
like this would need to be something which a user chooses instead of 
something which is imposed upon him.

that said, simply storing messages in the session instead of the 
request is a choice.  Perhaps if the bulk of people currently using 
that strategy (and I'm not one of them) agree that the benefits 
outweigh the costs, we could possibly say that it's part of the cost 
of using session-scoped messages...

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: ActionRedirect, saveMessages and Referer: keep messages in the session

[Michael Jouravlev <jm...@gmail.com>]

On 4/27/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Michael Jouravlev wrote:
> > Messages would pile up in the session. So what? The usability is more
> > important, is not it? Also, messages are saved per action/session, not
> > per action/session/item, so it is not that bad.
> 
> Potentially that is a big deal in terms of scalability and when dealing
> with a clustered eenvironment...
> ...
> In terms of scalability, you want to keep session as small as possible
> to not run server resources into the ground.
> ...
> I too am usually a "usability first" kind of guy, but I've also been
> bitten a couple of times by session size in these types of situations.
> This isn't at all meant to dissuade you from your proposal or otherwise
> critique it, but I thought this was a salient point to make.

I understand your point, but I just hate when they say: "we won't
implement this because it affects scalability, speed, cost of
equipment, etc". Isn't the whole thing for the end user after all???

Also, I've heard that certain session replication products (I don't
want to make an ad for Cameron) are quite good, and handle session of
several megs easily.

Also, it would be only one set of messages per action/session, not per
item! When the same user opens another item with the same action, old
messages would be cleared. So, the number of message blocks is limited
and can be calculated. So messages will not pile up uncontrollably.

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

Re: ActionRedirect, saveMessages and Referer: keep messages in the session

["Frank W. Zammetti" <fz...@omnytex.com>]

Michael Jouravlev wrote:
> Messages would pile up in the session. So what? The usability is more
> important, is not it? Also, messages are saved per action/session, not
> per action/session/item, so it is not that bad.

Potentially that is a big deal in terms of scalability and when dealing 
with a clustered eenvironment...

In terms of scalability, you want to keep session as small as possible 
to not run server resources into the ground.  True, you can simply add 
more memory, as cheap as it is these days that's the usual answer.  But, 
that's kind of tough to do mid-day when you for some reason (perhaps a 
bump in search ranking?) see a spike in requests coming in.  In general, 
you don't want to do anything that could potentially continue to add 
items to session in what might be an uncontrolled fashion (i.e., no 
valve to cut off the adds at some point).

In terms of a clustered environment, the session is constantly being 
replicated across the nodes of the cluster.  There are various schemes 
for when the replication occurs, I think most implementations tend to do 
it on calls to setAttribute().  In any case, session size can become an 
issue here quickly because serialization is usually involved, and the 
larger session is the longer that process will take, and the longer 
transmission over the wire will take, etc.

I too am usually a "usability first" kind of guy, but I've also been 
bitten a couple of times by session size in these types of situations. 
This isn't at all meant to dissuade you from your proposal or otherwise 
critique it, but I thought this was a salient point to make.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


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