Hello Endre!
This sounds swell! :-)))
Would be very glad to hear further discussion on the subject!
ES> Use a "poster"/"parameters" page, and a "renderer" page. This fools all
ES> browsers. This has indeed been up on the list a couple of times.
ES> The idea is that the poster accepts all the parameters,
Proposition: let us use some other terminology:
'poster' sounds confusing (to me at least)
maybe 'processor' will be better?
ES> and then just redirects your browser to the renderer.
:-))
ES> The browser sees this new redirect
ES> address, sees it being the same address as it rendered "the last time",
ES> and doesn't store a new history entry.
ES> If you follow this through, using
ES> only one poster
Do we strictly need one 'poster' ?
Sounds like we may have _any number_ of 'posters' ('processors' in
the new terminology) as soon as they all redirect to the same
'renderer'?
ES> and one renderer page
Yes, this is important!
ES> for your whole webapp, then you can
ES> click around your web application for hours, and then, when you click back
ES> one single time, you'll end up on NYtimes
:-)
ES> or whereever you came from in the first place.
BTW: it looks to me that it is worth exploring other designs too
and be more general
What we have now:
It is generally a good idea to send a redirect after a form
has been processed.
If we do not send a redirect after a form has been processed
two bad things may happen:
- if this was a POST request, the user will be prompted
with an upleasant dialog
- if the user answers 'yes' to this dialog, or if this
has been a GET request, the form will be processed
more then once, which is generally a bad thing
Let us call such design 'processor-renderer design'
meaning that the 'processor' part of code
(a servlet or a jsp) processes the form submitted
and throws a redirect. The part of code that
actually renderes the page (possibly even
the same servlet or a jsp) will be called
'renderer'.
Inside such 'processor-renderer design' I see
it usefull to outline 3 distinct subdesigns:
1) 'strict' subdesign
strictly one 'renderer' per application
'Back' button is disabled completely
it carries the user out of the application
2) 'sectioned' subdesigned
a very limited number of 'renderers',
each corresponding to a 'section' of the app
'Back' behaves as a 'good boy'
it switches the user to the previous 'section'
3) 'free' subdesign
any number of renderes is allowed
'Back' is not disabled at all, but
still 'processor-renderer design' retains
its strengthes (see above)
Ideas?
This is a bit scetchy..
Looks like the subject - 'designing the structure of
urls for a web app' deserves writing articles on it..
Are there any already available?
ES> --
ES> Mvh,
ES> Endre
--
Best regards,
Anton mailto:[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
