I understand the PRG pattern.  I don't see how it is relevant to the
Action vs. DispatchAction point.

Perhaps I'm just being dense... I am reviewing 3 gigs of server logs today
and my eyes feel like they are about to explode, and my brain is about to
turn to mush, moreso than usual I mean ;)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Thu, July 7, 2005 2:17 pm, Michael Jouravlev said:
> This is exactly what I mean. If you recall the definition, Location !URL.
> Instead, Location == URL + request params.
>
> Most browsers build up page history using locations, of the browsers
> known to me, only Opera uses actual responses. That means, that if you
> load the same page five times in Opera, it will put five entries into
> page history. But most other browsers do not do that, they put only
> one entry in page history, because all pages has the same location.
>
> Another trick is using redirection. Browsers "forget" location, which
> preceds redirected request. If you redirect from each POST to result
> page, result page is loaded with GET, this is how browsers work. Say,
> you submit the same form three times, you have the following request
> sequence: POST->GET->POST->GET->POST->GET, right? Three pairs of
> POST->GET What goes to the page history? The answer is, that requests
> preceding redirected request do not go, so it would be GET->GET->GET.
> This is what sucky Opera is doing. They explain this by 13.13 chapter
> of HTTP1.1 spec. Whatever. Other browsers do not do that, and also
> consider themselves compliant to HTTP spec.
>
> So, other browsers see that all GET in the GET->GET->GET point to the
> same location (see definition above). So, they just throw all of them
> but one, because they consider it the same resource. Now you get your
> page history: ->GET-> That is all!
>
> Now, combine that with non-cachable pages, and you can serve different
> content from the same locaiton, which is stored in the same history
> slot. This is how you get your single-page application or what I call
> it, a "web island". You cannot go Back, because there is nowhere to go
> back, and your page is always in sync with the server.
>
> This is what DialogAction does, besides other things ;-))
>
> I think I need to put "web island" chapter back into my article on JSP
> controls...
>
> Michael.
>
> On 7/7/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>> I don't understand your argument Michael.  Can you expand and/or
>> clarify?
>> Specifically, how is multiple Actions not serving from the same
>> location?
>> It's not the same URL, granted, is that what you meant?
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Thu, July 7, 2005 1:44 pm, Michael Jouravlev said:
>> > On 7/7/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>> >> (For any newbies reading this, the difference that matters is that
>> with
>> >> a
>> >> DispatchAction, you have a single entry in struts-config, but you
>> have
>> >> to
>> >> pass a parameter with each request.  With plain Actions, you would
>> have
>> >> multiple mappings like /setupForAdd, /setupForEdit, /add, /delete and
>> so
>> >> on in this case, but no parameter to pass around.  There are pluses
>> and
>> >> minuses to each approach, but they get you to the same basic place in
>> >> the
>> >> end.)
>> >
>> > Not really, unless you use mod_rewrite. Using single action allows you
>> > to serve all pages from one location, which, combined with redirect,
>> > usually makes a nice user experience. Most browsers put only one entry
>> > in the page history because the location is always the same for all
>> > response pages.
>> >
>> > Michael.
>
> ---------------------------------------------------------------------
> 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]

Reply via email to