I'm all for keeping this as a patch for now. Like I say, I'm reluctant
to add native PPR support to a non-portlet 2.0 framework. But I
certainly don't have any issues with keeping an interim solution around
that people can build themselves. I can't imagine that the patch is
THAT difficult to apply ATM..
Scott
Martin Marinschek wrote:
Hi Scott,
yes, I totally agree with all your statements - as I said before, my
work-arounds are a bit hacky, especially with regards to retrieve the
portlet id. I currently did it with an HttpSessionListener (and this
only works if the session is created before the first request to my
portlet-servlet happens).
My workaround for action-urls is now that I cache a generated
action-url from the portlet-view for the next view, the servlet-based
one. That works at least in Pluto, I haven't tried in Websphere so
far.
Sounds even more hacky, uuhh? Still, I have to do it, cause I'm a
programmer who gets paid for selling his mind, and obviously not for
selling his body (well, I wouldn't gain much from doing this ;)
In any case, I got Trinidad-PPR to run properly now on Pluto. Yeah!
Next will be WAS. Hope WAS won't generate major problems, even though
I'm afraid ;)
The only changes I had to do in Trinidad were:
1) change the URL of the PPR-request to send the request to a servlet
by providing a parameter with a special name
2) add some additional parameters in the PPR case
currently, I'm doing this centrally at one place (cause I only have to
support one portlet for my assignment, this is ok) but certainly, this
should be handled differently in the general case - like providing
these parameters in a call to partialSubmit? Overriding partialSubmit
in the portlet case with some special parameters, depending on the
portlet?
However, I'll also be ok if I have to patch every Trinidad version we
want to use for this, cause this is really too special - except you
guys think we should include it somewhere somehow, as other people
need it as well.
regards,
Martin
On 8/10/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
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
