Oops. Embarassing. I didn't reply to the whole list on purpose. Cynthia Harris wrote:
> 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
