Thanks Scott and Mike for all support. 2008/3/6, Scott O'Bryan <[EMAIL PROTECTED]>: > > Rog, > > Keep watch on the mailing list for announcements regarding releases of > Portlet-Bridge 2.0. That's the one that will have the eventing support. > > Scott > > > Rogerio Pereira wrote: > > Thanks for all answers Mike, I think you are on the right way, I'm > > about start a project that requires the event mechanism as described > > in JSR 286, after some research I found jboss portlet container 2.0 as > > the first usable implementation and now I use it, my first approach > > about jsf and portlet events worked as expected but with a very poor > > implementation (create FacesContext from factory and resolving the > > target managed bean), I'll continue my work on this project using JSP > > and JSTL but I'll create another version in JSF as soon as we have > > portlet events support on JSR 301 implementation. > > > > > > 2008/3/6, Michael Freedman <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>>: > > > > > 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: > > > > > 1. Activate FacesContext/Lifecycle/View/Restore bridge managed > > scope (as usual). > > 2. 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. > > > 3. 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. > > > 4. Wrap the request to hide PPRs from request(map) during > > > further processing -- note they are still available if call > > the getPublicRenderParameters api directly. > > > 5. Call lifecycle.execute (ensures that the model values are > > pulled into the view) > > 6. 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: > > > > > 1. Activate FacesContext/Lifecycle/View/Restore bridge managed > > > scope (as usual). If no bridge request scope, create one. > > > 2. 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. > > > 3. 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. > > > 4. Wrap the request to hide PPRs from request(map) during > > > further processing -- note they are still available if call > > the getPublicRenderParameters api directly. > > > 5. Call the configured EventHandler passing the Event request > > > (this allows the EventHandler to push the payload into > > associated MBs). > > > 6. Call lifecycle.execute (ensures that the model values are > > pulled into the view) > > 7. 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: > > > > > 1. Activate FacesContext/Lifecycle/View/Restore bridge managed > > scope (as usual) > > 2. 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. > > > 3. 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. > > > 4. Wrap the request to hide PPRs from request(map) during > > > further processing -- note they are still available if call > > the getPublicRenderParameters api directly. > > > 5. Only if we processed any PRP, call lifecycle.execute > > > (ensures that the model values are pulled into the view) > > > 6. Call lifecycle.render > > 7. Update VIEW_STATE_PARAM as usual > > > > PRPs received in Resource: > > > > 1. 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). > > > 2. 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. > > > 3. 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. > > > 4. Wrap the request to hide PPRs from request(map) during > > > further processing -- note they are still available if call > > the getPublicRenderParameters api directly. > > > 5. Call lifecycle.execute (besides processing the resource, > > > ensures that the model values are pulled into the view) > > > 6. Call lifecycle.render > > 7. 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: > > > > > 1. Activate FacesContext/Lifecycle/View/Restore bridge managed > > > scope (as usual). If no bridge request scope, create one. > > > 2. 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. > > > 3. 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. > > > 4. Wrap the request to hide PPRs from request(map) during > > > further processing -- note they are still available if call > > the getPublicRenderParameters api directly. > > > 5. Call the configured EventHandler passing the Event request > > > (this allows the EventHandler to push the payload into > > associated MBs). > > > 6. Call lifecycle.execute (ensures that the model values are > > pulled into the view) > > 7. 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) > >> > > > > > > > > -- > > 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) > >
-- 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)
