> -----Original Message-----
> From: Koen Segers [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 26, 2005 4:07 PM
> To: Tapestry users
> Subject: Re: postdata
>
> On Thursday 26 May 2005 02:23, Patrick Casey wrote:
> > Web browsers support two kinds of interactions with a server, POST
> > and GET.
> >
> > Most interactions are GETS.
>
> Form or url interactions?
> All our form interactions are POST...
Any time you push "submit" on a form it's a POST. Pretty much
anytime you push a link, it's a GET.
>
> >
> > When you submit a form though (or perform certain other actions
> > which cause javascript to submit a form for you), you use a POST which
> has
> > the advantage of not having a cap on the size of the transaction.
>
> OT: how is this different from GET?
Post encodes the contents of the currently active form and sends it
to the server. POST interactions do not have a cap on the amount of data
that can be pushed, while GET interactions are limited by the MAX_URL size
(1024 bytes if memory serves).
>
> >
> > Both POST and GET allow the web server to respond. Most first time
> > web app designers typically send a response page up in response to a
> POST
> > e.g.
> >
> > 1) User submits form
> > 2) Server handles post
> > 3) Server replies with "record saved" or something analogous
> >
> > This, in a nutshell, is wrong because ...
> >
> > 4) User pushes refresh.
> > 5) Refresh causes browser to re-execute whatever action resulted in the
> > current page. Net result is it tries to "double post". Most modern
> browsers
> > try to prevent double posts by warning you with some variant on the
> > "refreshing requires resending POST data" message.
> >
> > The way around this is to implement the POST->redirect->GET web
> > pattern.
> >
> > 1) User submits form.
> > 2) Server handles post.
> > 3) Server replies with a redirect.
>
> You mean a cycle.activate("somepage"); ? isn't this what was wrong?
Nope, I mean reply with a redirect instruction. In tapestry the way
to do that is to throw a pageredirectexception.
>
> > 4) Browser catches redirect and does a GET for the 'record saved' page.
>
> I want an automatic refresh of the form page, not of the "message" page...
>
> >
> > Since in this pattern the ack page is the result of a GET, not a
> > POST, it's refresh (and back) button safe.
>
> I think I don't get the point totally. Can you be a bit more precise?
>
> Suppose you have redirected to a message page. If the user presses "back"
> it
> isn't refresh (and back) button safe, is it?
If you've redirected then sure it's safe because what you're
refreshing is the GET.
Here's somebody elses more long winded explanation of the
post->redirect-> get pattern.
http://www.theserverside.com/patterns/thread.tss?thread_id=20936
>
> Thx very much for the quick answer !!!
> I appreciate it !
>
> Greetz ;)
>
> >
> > --- Pat
> >
> > > -----Original Message-----
> > > From: Koen Segers [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, May 25, 2005 3:44 PM
> > > To: Tapestry users
> > > Subject: Re: postdata
> > >
> > > On Wednesday 25 May 2005 20:01, Robert Zeigler wrote:
> > > > That's actually a browser-generated message, and not something
> specific
> > > > to any website or framework.
> > >
> > > I'm not fully convinced. Using the same browser on several forms will
> not
> > > always generate this message. It is actually rare to get this message
> ...
> > >
> > > Greetz
> > > --
> > >
> > > Koen Segers
> > >
> > > <[EMAIL PROTECTED]>
> > > <http://eddyvite.dyndns.org>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
>
> Koen Segers
>
> <[EMAIL PROTECTED]>
> <http://eddyvite.dyndns.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
