Not only that but from an AJAX perspective, action urls (which are
guarenteed to be "in-context") always have portal baggage attached that
much up the XmlHttpRequest payload, and in JSR-168, resource request are
NOT guaranteed to be in-context. JSR-286 addresses this formally. As
for the sessions, there is no way in JSR-168 to obtain the portlet id.
Generally this will be the same as the namespace, but it is not
guaranteed. Therefore, even if resource requests WERE in-protocol (and
have access to the session) the portlet-scoped session would still not
be available. JSR-286 will hopefully solve this because it will allow
both in-protocol resource requests as well as add special support for AJAX.
Until then, though, you might be able to get something to work in Pluto,
or WebSphere or the Oracle Portal, but they would likely be proprietary
solutions.
Scott
Martin Marinschek wrote:
Hi Scott,
yes, sure, we were saying this initially - if we suspect a portlet and
a servlet share the same session, then we can't distribute the
portlets via WSRP.
regards,
Martin
On 8/8/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
Hey Martin,
Many of this stuff also won't work in a "remote portal" behind WSRP.
The portal enhancements I made to Trinidad work for portal PPR, but it's
going to be container specific until 286 comes out. I don't think we
should be adding portal specific changes to Trinidad personally.
Scott
Martin Marinschek wrote:
Next step in my quest for full trinidad and portlet compatibility was PPR:
I've done the following:
- tweaked trinidad to send some additional parameters with each partial request
- tweaked my portlet-rendering code to include the portlet-prefix (in
the session/application-map) as one of these additional parameters
(retrieving the portlet-prefix is still kind of interesting code, I'll
have to bring this to maturity, but currently, I ownly rely on the
servlet- and portlet-API)
- tweaked the trinidad partial submit routine to post these additional
parameters to a different action then the one mentioned in the form
- behind this action, have a servlet listening for all incoming requests
- the servlet wraps request/session/context and uses the
portlet-prefix to access attributes in the session/application map, so
the servlet knows how to access the corresponding portlet parameters
- the servlet sets the UIViewRoot onto the FacesContext so that the
UIViewRoot is available
- the servlet then executes a full lifecycle
This all works pretty nicely, until we get to the point of someone
calling url-encoding methods while the rendering in the servlet
happens.
And this is where I'm at now. Without being in the portlet container,
I of course have no way of deriving a portlet-URL. So I strongly
suspect I'm stuck for good now, and I need to restart with better
ideas. Anyone having some?
regards,
Martin
