yes it is "Resource serving" (first option)
On 10/24/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
Arash, they are also adding a mechanism specifically to handle AJAX. Arash Rajaeeyan wrote: > Hi scott, > > you are right JSR 286 has non of these problems because they have added > Resource Serving and Portlet filter concepts: > > PLT.13 page 67 > Resource serving – provides ability for a portlet to serve a resource.. > PLT 19 page 199 > Portlet filter – allowing on the fly transformations of information in > both > the > request to and the response from a portlet > > > I think if want to add a filter for image and other resources, this > should > also do the job of ajax calls, and if use another method, we should still > find a way for ajax calls and we will probably do same work twice > > 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
