portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cynthia Harris <cynt...@atg.com>
Subject Re: Turbine - Jetspeed interaction problems
Date Tue, 26 Mar 2002 17:23:17 GMT
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.


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:ggolden@umich.edu]
> 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
> ggolden@umich.edu               734-615-1419
> http://www-personal.si.umich.edu/~ggolden/
> --------------------------------------------
> --
> To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message