if we forget about ajax what about immediate, is there any facility in trinidad which shortcuts lifecycle?
On 10/24/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
Arash, Hey Arash, thanks for the links. The problem is that finding an AJAX solution will pretty much trump any other work we have. While certain portal implementations can be exploited to provide what is needed for AJAX, none of them are guaranteed with JSR-168. The real problem with AJAX and portletshas nothing to do with the life cycle. It more has to do with limitations of JSR-168. Let me elaborate. JSR-168 containers do not guarantee that a particular call to a resource is in the same namespace as it's parent application. This is typically the case in WSRP containers. Even assuming we could be connected to the same session as a particular portlet, the session data for a portlet instance is prefixed with a "javax" prefix and the portlet id. While this is SOMETIMES the same as the namespace, the JSR-168 does not guarantee this and there is no API for getting a hold of the portlet Id. Portlet 2.0 Spec is supposed to have some mechanisms for handling this, but anything we put in place in the mean time to handle AJAX will not work in all containers. Therefore, I'm of the opinion that we should get Trinidad working without AJAX first, making it the most compatible with JSR-168, and then look at possibly enhancing it to take a advantage of some specific portlet container implementations that might be exploited for AJAX. Until the portlet 2.0 specification is released, JSR-168 will not be able to support AJAX in all cases natively, or at the very least not in a fashion that is as secure as the web container. Scott Arash Rajaeeyan wrote: > Hello, > First let me tell, that since lifecycle of Portlets is different with > Servlets, so the same implementation of the JSF life cycle for servlet is > not necessarily good for portlets too. > > I didn't find an exact case in Trinidad sources, but there are should be > some facilities similar to tomahawk "immediate" attributes ( > http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works) > > Which some time short cut the lifecycle. So I think this should be taken > into account > > If we can find a method for handling AJAX requests at same time is also > good. The problem is every AJAX call to a portlet will generate a > processAction and as a result will refresh all portlets in a page > unnecessarily. > > For more information about this you can see the following articles: > > http://developers.sun.com/prodtech/portalserver/reference/techart/asynch_rendering.html > > > http://blogs.sun.com/gregz/entry/ajaxportlet_updates#comments > > http://developers.sun.com/prodtech/portalserver/reference/techart/ajax-portlets.html > > > Arash Rajaeeyan > > On 10/23/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote: >> >> We discussed this in 10.1.3 about how there is no guarantee that the >> "cleanup" will happen if the life cycle is short-circuited.plus we would >> need a bunch of touch-points. We would need listeners on the following: >> >> 1. Initialize before Restore Component Tree >> 2. Cleanup after Process Events only when Response Complete or Render >> Response is the next phase >> 3. Cleanup after Process Events only when Response Complete or Render >> Response is the next phase. >> 4. Cleanup after Process Events only when Response Complete or Render >> Response is the next phase >> 5. Cleanup after Process Events 2 >> 6. Initialize before Reader Response >> 7. Cleanup after Reader Response >> >> It would be far easier to run the execution code at the beginning and >> end of the LifeCycle's "execute" method and at the beginning and end of >> the lifecycle's "render" method just to make sure we hit all the touch >> points. >> >> Also, some of the cleanup above (ie. cleaning up before Render Response >> and then reinitializing could be optimized, but do remember that in the >> portal, each portlet can recieve multiple render-requests for each >> action request. So the TrinidadFacesContext object should be the same >> between those calls to render-request. I've just added some code in >> 10.1.3 that was causing issues with this and process scope. Of course >> when dealing with servlets, this all becomes trivial. >> >> Now that being said, if you still think LifeCycle listeners are the way >> to go, I would be happy to explore that option. I know this is the type >> of stuff that LifeCycle listeners were designed for, but I also know >> there was a reason that Trinidad used filters instead of lifecycle >> listeners before. Eliminating the need for filters altogether would be >> a good thing. >> >> Scott >> >> Adam Winer wrote: >> > On 10/20/06, Scott O'Bryan < [EMAIL PROTECTED]> wrote: >> >> >> >> My question is >> >> this, is there any reason we can't provide our own custom lifecycle >> >> object that decorates the default one and allows us to run our >> >> initialization code on the execute and render? If so, the code to >> >> manage things like the TrinidadFacesContext becomes a LOT easier >> and we >> >> can rely on some of the stuff already build in to the Bridge >> Portlets. >> > >> > >> > >> > What's the advantage of a custom lifecycle over using >> > a phase listener? >> > >> > --Adam >> > >> >> >
-- Arash Rajaeeyan
