Re: About Portlets 2.0 and JSF

[Michael Freedman]

FYI ... here are the preliminary thoughts related to Portlet 2.0 Coordination features (events and public parameters) that are being worked on in the JSR 301 EG -- the plan is to have an Early Public Draft and hopefully an basic impl of the RI (MyFaces PortletBridge project between mid-April and mid-May. Portlet Coordination:  Public Render Parameters Summary: Idea is to map PRPs (and events) as alternative input to models.  Because JSF doesn't really have concept of render parameters (i.e. state not remembered/reflected in the view state/models) the bridge makes PRPs look more like events.  I.e. PRPs in JSR 286 are resupplied on each request hence the portlet isn't expected to retain their state -- rather they merely render using this additional information.  In Faces we map directly to the models where we expect this state to be preserved @ some scope, or in the view state, or in the bridge request scope.  The model mapping is accomplished via a new faces-config bridge application-extension.  The extension names a PRP and defines the associated Faces EL it executes.  Received PRPs have the associated set accessor of this EL executed.  The get accessors are called at end of lifecycle to see if there are new values to be returned.  It will works as follows: PRPs received in an Action: Activate FacesContext/Lifecycle/View/Restore bridge managed scope (as usual). Check request parameters for PRPs.  For each PRP execute the associated set accessor on the EL mapped to this PRP passing the value of the parameter. As parameters are String only, the accessors must also be String typed.  I.e. we don't do type conversion -- in part because we expect the model to have to distinguish between being updated via a PRP vs. regular Faces execution -- hence potentially a discrete accessor for PPRs that then push into the regular model field. If the portlet has configured an EventHandler call it passing a well known Event representing PublicRenderParametersChanged (pass request so handler can see the PPRs if needed).  This allows event handler to trigger any needed model updates/recomputations. Wrap the request to hide PPRs from request(map) during further processing -- note they are still available if call the getPublicRenderParameters api directly. Call lifecycle.execute (ensures that the model values are pulled into the view) Process result of action/save bridge request scope as usual except re-execute all mapped PRP Expressions (call the getters) and for each that yields a result different then what is in the request -- return a new PRP/value.  Open question:  only check those params that were in the request or all mapped PPRs?  I would argue that we do all and for any that return null we delete the PPR from the response.   PRPs received in Events: Activate FacesContext/Lifecycle/View/Restore bridge managed scope (as usual). If no bridge request scope, create one. Check request parameters for PRPs.  For each PRP execute the associated set accessor on the EL mapped to this PRP passing the value of the parameter. As parameters are String only, the accessors must also be String typed.  I.e. we don't do type conversion -- in part because we expect the model to have to distinguish between being updated via a PRP vs. regular Faces execution -- hence potentially a discrete accessor for PPRs that then push into the regular model field. If the portlet has configured an EventHandler call it passing a well known Event representing PublicRenderParametersChanged (pass request so handler can see the PPRs if needed).  This allows event handler to trigger any needed model updates/recomputations. Wrap the request to hide PPRs from request(map) during further processing -- note they are still available if call the getPublicRenderParameters api directly. Call the configured EventHandler passing the Event request (this allows the EventHandler to push the payload into associated MBs). Call lifecycle.execute (ensures that the model values are pulled into the view) Process result of action/save bridge request scope as usual except re-execute all mapped PRP Expressions (call the getters) and for each that yields a result different then what is in the request -- return a new PRP/value.  PPRs received in a Render: Activate FacesContext/Lifecycle/View/Restore bridge managed scope (as usual) Check request parameters for PRPs.  For each PRP execute the associated set accessor on the EL mapped to this PRP passing the value of the parameter. As parameters are String only, the accessors must also be String typed.  I.e. we don't do type conversion -- in part because we expect the model to have to distinguish between being updated via a PRP vs. regular Faces execution -- hence potentially a discrete accessor for PPRs that then push into the regular model field. If the portlet has configured an EventHandler call it passing a well known Event representing PublicRenderParametersChanged (pass request so handler can see the PPRs if needed).  This allows event handler to trigger any needed model updates/recomputations. Wrap the request to hide PPRs from request(map) during further processing -- note they are still available if call the getPublicRenderParameters api directly. Only if we processed any PRP, call lifecycle.execute (ensures that the model values are pulled into the view) Call lifecycle.render Update VIEW_STATE_PARAM as usual PRPs received in Resource: If there is a bridge managed scope, restore it but don't copy the managed request attributes back into the request.  Otherwise create a scope (ID will have to be maintained in session until next full action). Check request parameters for PRPs.  For each PRP execute the associated set accessor on the EL mapped to this PRP passing the value of the parameter. As parameters are String only, the accessors must also be String typed.  I.e. we don't do type conversion -- in part because we expect the model to have to distinguish between being updated via a PRP vs. regular Faces execution -- hence potentially a discrete accessor for PPRs that then push into the regular model field. If the portlet has configured an EventHandler call it passing a well known Event representing PublicRenderParametersChanged (pass request so handler can see the PPRs if needed).  This allows event handler to trigger any needed model updates/recomputations. Wrap the request to hide PPRs from request(map) during further processing -- note they are still available if call the getPublicRenderParameters api directly. Call lifecycle.execute (besides processing the resource, ensures that the model values are pulled into the view) Call lifecycle.render Save request scope into bridge request scope (use fixed up VIEW_STATE_PARAM).  The result should be a current reflection of request scope data needed to render the current page entirely. Portlet Coordination:  Events Summary: Call a portlet configured event handler to allow the client code to directly push the event payload into the underlying models.  This will most likely use JSF EL to do the push.  I.e. unlike PRPs the event payloads are arbitrary/complex types hence its prohibitive for us to use declarative mapping (at this point).  Rest of processing is as described above -- we execute the lifecycle (lifecycle.execute) so the View can pull new values based on any underlying model changes and then we process the result in a manner similar to how we currently handle actions: Activate FacesContext/Lifecycle/View/Restore bridge managed scope (as usual). If no bridge request scope, create one. Check request parameters for PRPs.  For each PRP execute the associated set accessor on the EL mapped to this PRP passing the value of the parameter. As parameters are String only, the accessors must also be String typed.  I.e. we don't do type conversion -- in part because we expect the model to have to distinguish between being updated via a PRP vs. regular Faces execution -- hence potentially a discrete accessor for PPRs that then push into the regular model field. If the portlet has configured an EventHandler call it passing a well known Event representing PublicRenderParametersChanged (pass request so handler can see the PPRs if needed).  This allows event handler to trigger any needed model updates/recomputations. Wrap the request to hide PPRs from request(map) during further processing -- note they are still available if call the getPublicRenderParameters api directly. Call the configured EventHandler passing the Event request (this allows the EventHandler to push the payload into associated MBs). Call lifecycle.execute (ensures that the model values are pulled into the view) Process result of action/save bridge request scope as usual except re-execute all mapped PRP Expressions (call the getters) and for each that yields a result different then what is in the request -- return a new PRP/value.  Scott O'Bryan wrote: There is going to be a spec covering this as part of JSR-301, but although it's well under design, there is not a public draft released yet.  We are trying to get the 168 bridge out first. Scott Rogerio Pereira wrote: Hi guys! I saw the list of speakers at JSFDays and the topics to be discussed, I'm specially interested about portlets and jsf topic because I have been working on portlets recently, I could use jsf and facelets without any problems on liferay and some others portal implementations but now I need to use the event mechanism as defined in JSR-286, how can we handle this kind of feature when using jsf as framework to develop portlets? My first thought is related with some kind of interface and can used to indicate which beans will publish/listen portlets events. Right now we have JBoss Portlet Container 2.0 as the only portlet container that supports JSR-286, I would like to know what you guys think about portlets events and jsf topic. --  Yours truly (Atenciosamente), Rogério (_rogerio_) http://faces.eti.br "Faça a diferença! Ajude o seu país a crescer, não retenha conhecimento, distribua e aprenda mais." (http://faces.eti.br/?p=45)