On 11/9/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]
> wrote:
What happens when you have two windows or frames, and the user has navigated to the same page?
Shale is very modular ... you can easily use the token component (and tag) from shale-core.jar without using any of the rest of it (at least if you use the daily builds, where a lot of the original stuff has been factored into separate libraries so you can use just what you want :-).
The token component is focused on detecting a second submit of the same page, and triggering a validation error if this happens. The technique it uses works with multiple frames/windows, even if they are displaying the same page, because it is tracking the values of a hidden field that gets rendered as part of the page, not what the view ids are.
Hi Simon,
thx for your answer! I've added my comments inline:
> When using client-side caching, it happens automatically, because after
> the user clicks "back" then submits a form, the old saved component tree
> gets submitted back to the server and hence the old component tree gets
> restored.
> When using server-side caching, the last N component trees are stored in
> the http session, where N defaults to 20 but can be configured in the
> web.xml (sorry, can't remember the key).
Yes, I know, I've used client side state saving for a long time... this
seems to be the version with fewer problems, because as you've already said,
the component tree gets encoded and sent to the client with the request...
so the client has to send it to the server again on each request.
That's why I've switched to server side state saving. My pages had about 100
kb or even more, and using the web application was too slow when using
client side state saving. I am now using server side state saving with
NUMBER_OF_VIEWS_IN_SESSION set to 1. (I think that's how the parameter is
called).
> The code that looks up the view is in JspViewHandlerImpl.java which
> delegates to JspStateManagerImpl.java (method restoreView). For
> server-side state, this clearly gets a "sequenceString" which is used to
> determine which of the cached component trees to use.
> HtmlResponseStateManager.getTreeStructureToRestore looks in three
> *request parameters* for data:
> * jsf_viewid
> * jsf_tree
> * jsf_tree_64
> so I would guess that these fields are automatically inserted into every
> form in the html page when using server-side state saving. I can't check
> this as the work I'm currently doing uses client-side state saving.
Well... that sounds promising... having a viewed in each request would be
fine, because then it's possible to detect these resubmitted pages... It
would be possible to store the used viewids in session scope bean and then
compare each submitted id with the ids already stored....
What happens when you have two windows or frames, and the user has navigated to the same page?
Good idea, thx.. I will look that up tomorrow.. ;)
> The Shale library (shale.apache.org) provides a bunch of useful
> utilities for JSF, including a <token> component that I think does this
> sort of checking:
> http://shale.apache.org/shale-core/tagreference.html
Well... I might take a look at that too, but at the moment I don't want to
add another framework... At the moment I've enough of that :D.
Shale is very modular ... you can easily use the token component (and tag) from shale-core.jar without using any of the rest of it (at least if you use the daily builds, where a lot of the original stuff has been factored into separate libraries so you can use just what you want :-).
The token component is focused on detecting a second submit of the same page, and triggering a validation error if this happens. The technique it uses works with multiple frames/windows, even if they are displaying the same page, because it is tracking the values of a hidden field that gets rendered as part of the page, not what the view ids are.
> However there are any number of JSP tags around to do this (just
> google), and I don't see why they can't be used together with JSF, ie
> why a JSF-specific solution is needed.
I will take a look at these...
Thx,
Dominik
Craig
