> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
