On 3/15/06, Leon Rosenberg <[EMAIL PROTECTED] > wrote: > > Speaking of JSF, > is there somewhere a Filter or n extension allowing you to use > JSF/Shale/MyFaces without having a single url and send everything over > POST? > Until there is one, I don't see how you can use JSF in portals, but if > there is one, I'd love to try it out :-)
There is not yet (filters are not supported in Portlet 1.0), but believe me ... the folks on the Portlet 2.0 expert group are hearing about this kind of requirement. In the mean time (as usual when the standards lag) you'll see individual products offer interim solutions to this problem. However, JSF is still usable in portals today ... there are at least three technologies available (which differ in details but are based on the same fundamental ideas): * MyFaces has an integration library (http://myfaces.apache.org) * The Apache Portals project has a generic briding library that includes support for JSF (as well as for Struts). ( http://portals.apache.org) * Java Studio Creator apps can take advantage of the "jsf-portlet.jar" library available with the JSF RI. In all three cases, the concept is to map the Portlet API "processAction()" method to the Restore View through Invoke Application phases of the JSF ifecycle, and to map the "render" method to the Render Response phase. The interesting part of programming portlets is that the render phase will get called for *all* JSF-based portlets on the page, while the action stuff is only called on the portlet to which the form submit was directed. In practice, that means you need to ensure that you have access to whatever state you need to rerender yourself at all times, even if you didn't receive the submit. (Shale's prerender() and destroy() methods work particularly nicely in this scenario, as they are called for you before and after the rendering of each individual portlet). regards > Leon Craig
