See public final Response getOriginalResponse()
But what do you do there exactly?
I think the problem is that you also want to do something in the 'real' render request?
If that is the case then yes the BUFFER stategy will never work because then you are writing
things to the request response when it renders but the actual result is send in the redirect response
And at that time you don't have any callbacks to the code (you look at wicketservlet.get() how that works)
On 10/8/05, Scott Sauyet <
[EMAIL PROTECTED]> wrote:
As far as I can tell, it doesn't matter when, as long as I have access
to the actual HttpServletRequest/Response. I think I'll probably just
follow Igor's advice and switch to the ONE_PASS_RENDER strategy. I'm
not worried about clustering or anything complicated.
Thanks for your help.
-- Scott
Johan Compagner wrote:
> and at what time do you want to do that piece of code?
>
> On 10/7/05, *Scott Sauyet* <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>>
> wrote:
>
> Johan Compagner wrote:
> > The question is why do you really need that voodoo on the real http
> > request? As a wicket user you shouldn't
> > touch those objects. (ofcourse there could be thing where you
> need them
> > but try to avoid it as much as possible)
> >
> > What are you setting/using those objects for? And when?
>
> Sorry, an old USENET habit maked me try to keep only the minimally
> necessary amount of quoted material in my email. So I ruthlessly chop
> out much of the context in my responses.
>
> The reason I need this is that I was told near the end of this fairly
> simple project that, "Oh yeah, by the way, you need to make sure this
> runs inside of Plumtree Portal." I was told originally that this would
> be inside Plumtree, but that I didn't need to do anything special for
> that. That turned out to be wrong. There is some work to do.
>
> I don't know exactly how Plumtree works, but I know that I am not
> writing to the Portlet spec. My code runs entirely stand-alone. But
> Plumtree can also embed it inside the portal page. What I believe it
> does is to make an HTTP request for my page, buffer the response,
> altering any SRC and HREF attributes to point to new URLs that include
> the Portal page address, and embed this new output inside the final
> portal page. For some reason, all this requires that the portlet page
> access the HttpServletRequest/Response objects. [1]. If I address this
> page standalone instead of through the Portlet, I get the console output
> generated inside that catch clause.
>
> I don't know what voodoo Plumtree does at this point; I would assume
> that the URL rewriting has to happen inside Plumtree's server. But
> something must happen here. This is what I was told I had to do.
> Everything worked fine for some pages: the main page and the
> BookmarkablePages all worked just fine. But other pages, although my
> stuff rendered fine, did not end up inside the Plumtree shell. I'm sure
> this has something to do with the redirecting, but I don't know any
> details right now.
>
> That's the reason, anyway. A lot of this is still black magic to me,
> including great swaths of the Wicket core, but I'm learning.
>
> Thanks for your help,
>
> -- Scott
>
> [1] Portlet-related code:
> ServletWebRequest servletWebRequest = (ServletWebRequest)
> getRequest();
> HttpServletRequest request =
> servletWebRequest.getHttpServletRequest();
>
> WebResponse webResponse = (WebResponse)
> getRequestCycle().getOriginalResponse();
> HttpServletResponse response =
> webResponse.getHttpServletResponse();
>
> try {
> // Get the Portlet Context
> IPortletContext pContext =
> PortletContextFactory.createPortletContext(request, response);
> IPortletResponse pResponse = pContext.getResponse();
> // Set hosted display mode
> pResponse.setHostedDisplayMode(HostedDisplayMode.Hosted);
> } catch (Exception e) {
> System.out.println("Get Portlet Context Failed with --
> " + e);
> }
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> <mailto: Wicket-user@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
