Ahh, good question, and I did try using <map:read>, but it didn't work. And yes, my usage case is a bit more complex than I've shown. Here's an example of my sitemap snippet:
<map:match pattern="modifyCart"> <map:act type="modify-cart"/> <map:redirect-to uri="cocoon:/showCart"/> </map:match>
<map:match pattern="getCartInfo"> <map:act type="update-cart-item-quantities"/> <map:generate src="myapp/xml/getCartInfo.xsp" type="serverpages"/> <map:serialize type="xml"/> </map:match>
<map:match pattern="showCart"> <map:aggregate element="cart-page"> <map:part src="cocoon:/getCartInfo" strip-root="true"/> ... </map:aggregate> <map:serialize type="xml"/> </map:match>
Now, if I replace <map:redirect-to uri="cocoon:/showCart"/> with <map:read uri="cocoon:/showCart"/>, then the actions in "getCartInfo" actually get executed *twice* instead of just once like I want. I don't understand why this happens, but it is undesirable since request attributes I use to display the final output get overwritten if these actions are called twice.
I'd love to know why the actions get executed twice with <map:read>, but I'd also like to know why request attributes don't persist for internal redirects.
Overall, it doesn't seem like I can alter these things, so I decided to just use a session attribute and remove it after displaying the data (since sessions *do* persist across redirects).
Sonny
From: "Jay Freeman \(saurik\)" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> Subject: Re: new Request for internal map:redirect-to's? Date: Mon, 18 Aug 2003 13:23:51 -0500
Sonny:
Isn't what you're asking for capable of being done with a <map:read src="cocoon:/.."/> instead of a <map:redirect-to/>? Or is your actually usage case more complicated than your examples. I could almost understand redirect-to trying to simulate what would happen if a Location header _had_ been sent, except doing it more efficiently, and expecting developers to just read the data from the other file if that's what they wanted.
Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED]
----- Original Message ----- From: "Sonny Sukumar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 18, 2003 1:16 PM Subject: Re: new Request for internal map:redirect-to's?
>
> Alright, I tried logging the hash codes of the Request instance within the
> first pipeline, and then in the redirected to pipeline, and the hash codes
> are always different. Moreover, it doesn't look like HttpRequest
overrides
> the hashCode() method (looking at the Cocoon API docs), so it's probably
> just based on memory location or something. This is probably a good
> indication that the objects are different (and hence contain different
> info), since the object probably wouldn't be moved just for a redirect.
>
> In any case, it kind of sucks to resort to storing the things in the
session
> that I only want to persist for the duration of the request and then have
to
> delete them. It seems to me that if request params can be preserved for
an
> internal redirect, then why not request attributes as well? Of course, I
> might not be seeing some design issue, but it'd be good to know *what* I'm
> not seeing. ;-)
>
> Let me know what you think,
>
> Sonny
>
> >From: Upayavira <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: Re: new Request for internal map:redirect-to's?
> >Date: Mon, 18 Aug 2003 11:55:47 +0100
> >
> >Sonny Sukumar wrote:
> >...
> >
> >>Anyhow, with all that said, my original question still stands: Is a new
> >>Request instance still produced when such an internal redirect is
handled?
> >> See my sitemap snippet below:
> >>
> >><map:match pattern="someUri">
> >> <map:action type="some-action"/>
> >> <map:redirect-to uri="cocoon:/anotherUri"/>
> >></map:match>
> >>
> >><map:match pattern="anotherUri">
> >> ...
> >></map:match>
> >>
> >>In the "some-action" action, I set a Request attribute, which is gone by
> >>the time "anotherUri" produces output. I know it is being set properly
> >>since I've logged it and it looks fine.
> >
> >From a cursory look at the code, it seems that the query string should
> >survive, but I'm not so sure about form parameters. Do you use POST or
GET?
> >If you use POST, can you switch to GET and see if it now works?
> >
> >Regards, Upayavira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
