Hi Craig, I'm not replying to the whole list because I'm kinda new around here and I don't know the ropes.
The form handling technique that I use would help you out. In J2EE, I think the standard form handling technique is to put the form on some page, and make the action of the form point back to the same page. On the next time the page comes up, before there is any content, the form data gets processed and then the redirect would occur. Right? In the system that I use, the form's action is again the same page. The difference is that the form data is processed and the redirect occurs before the next page is served. This is the standard technique used in ATG's Dynamo App Server. We've been using it for years and it works great. If you want more info on this, let me know. I've been taking this system for granted for so long, that I need to think about it before I could tell you how to build such a system. -Cynthia PS. On Monday, I posted what I thought were some easy questions to the jetspeed-users list. Do you know if anyone is thinking about answering those? I'm very eager to have the answers, but I don't want to be a total pest on the list. Thanks! "Setera, Craig" wrote: > I'm in agreement with Glenn that redirect's are necessary here or at least > the behavior we get when we redirect. I've found no other good solution > within the limits of HTTP to make the browser do the right thing. I > originally asked for redirects in Jetspeed a few months back because of the > errors that would arise if the user pressed the back or reload buttons in > certain situations. It is a bit more traffic, but I believe it is more > "correct" from the user's perspective. > > If anyone has another way to do this without redirects and still preserve > the "user experience", I would love to hear it. I could use something like > that in other web applications. > > Craig > > -----Original Message----- > From: Glenn Golden [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 8:41 AM > To: 'Jetspeed Developers List' > Subject: RE: Turbine - Jetspeed interaction problems > > Yes, it means all this extra traffic. But is the cost worth the benefit? > > The goal is to get the browser to have a good URL, one that could be > "reloaded" or "back"ed without fuss and bother. If we are customizing, or > doing other things that use a different url, and want to switch back to the > portal, we could internaly redirect things so that we respond to an action= > sort of URL with the same response as the /portal one, but then the browser > will be confused if the user hits reload. > > A cool solution that lets us send whatever HTML we want AND fix the > browser's URL so that a refresh or back button would get this HTML again, > would be to internally route the request where we want it (somehow), and > then as part of the HTTP headers, tell the browser that, in effect, here's > the *real* URL that goes with the response, forget what the request URL > was... I wonder if there's a way in HTTP to do this? > > - Glenn > > -------------------------------------------- > Glenn R. Golden, Systems Research Programmer > University of Michigan School of Information > [EMAIL PROTECTED] 734-615-1419 > http://www-personal.si.umich.edu/~ggolden/ > -------------------------------------------- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
