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 > >>> > >>> > >>> > >> > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
