struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: [ANNOUNCEMENT] Struts Dialogs: DispatchAction on steroids
Date Thu, 09 Jun 2005 08:34:09 GMT
Yes but what about Netscape 4?  .... only kidding :)

The effect is neat however you do have to implement the no-cache and you 
have to turn off auto-validation and then rely on the browser, so I 
wonder whether it is really neat enough to be worth it.  I do prefer 
things to be as simple as possible, if not for robustness then just to 
make it easier for struts-newbies to take on board.


On 09/06/05 01:22&nbsp;Michael Jouravlev wrote:
>>I don't understand how you managed to get the page with validate-error
>>not to make an entry in the browser history. I see you've turned off
>>automatic validation but closer than that I'm not sure. It seems to be
>>linked to the no-cache stuff but I didn't think the caching had anything
>>to do with the browser history.
> Pretty neat, huh? ;-) Does not look this slick on sucky Opera.
> I turned validation off, so that action class is called even if input
> data is not valid. Action must always be called, it does the
> processing, it is a switchyard between GET and POST, it creates and
> stores error and clears error messages, and it dispatches the request.
> No-cache helps to reload a page. You can see in the sample app, that
> without no-cache setting you need to manually reload a page to see
> current server standing.
> So, the page must be always reloaded to keep browser in sync with the
> server. How exactly the history is kept from growing, is explained
> further (almost quoting my own article, hence more formal style):
> DialogAction uses a couple of tricks:
> First is to serve different content from the same location. And by
> saying "same" I mean exactly the same, including the number, names,
> and content of request query parameters. Internet Explorer and
> Mozilla/Firefox build session history based on resource location. They
> do not include resources from the same location into the history. For
> example, Login Control has two pages, "Not Logged In" and "Logged In",
> each reflecting the web control state. Both pages are served from the
> same location, which is the action URL. No additional parameters are
> passed to action to trick the browser into thinking that it is the
> same page.
> Another trick is redirection: according to HTTP specs, when a browser
> is redirected from a POST request, the resource identified by original
> POST request must not be stored in the session history. Some browsers
> like Internet Explorer go further and do not cache response for
> original request even if the request has the GET type. This is how
> initialization works, it uses GET with init parameter, and then
> redirects to "clean" action location with no parameter, so browser
> would not store URL with parameter in the history. Hmm, that seems to
> work on Firefox too... I should re-read the specs ;)
> Working together, these tricks result in a neat effect: a browser
> thinks that it _keeps reloading the same page_. Thus, the browser
> prevents a user from going back to see the stale data or to resubmit
> the stale form.
> If this approach does not work with a particular browser, and the
> browser accumulates every page in its history, then the application
> falls back to the Redirect-After-Post pattern.
> The DialogAction was tested on Windows 2000 with Internet Explorer,
> Netscape Navigator, Opera, and Firefox (make sure that you use the
> official release of Firefox, which fixes the bug with no-store
> cache-control header). Opera is the bad boy, it tries to cache
> everything. It interprets the HTTP standard differently from Internet
> Explorer and Firefox, and does not reload a page when a user navigates
> back, even if page is marked as "no-store". Thus, it is possible to
> resubmit a stale form from Opera. Sucky, sucky Opera.
> For the record: I did not invent anything here. I mean, I did, I
> reinvented the wheel, because after I came up with these tricks, I
> googled specifically for this kind of stuff, and found several sites,
> which use these tricks too. Still, it is not commonplace.
> Michael.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message