Sure, sounds good. Would also be my decision. regards,
Martin On 8/13/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >> > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
