On 10/7/05, Scott Sauyet <[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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
