myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rogerio Pereira" <rogerio.ara...@gmail.com>
Subject Re: About Portlets 2.0 and JSF
Date Thu, 06 Mar 2008 17:03:24 GMT
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 <michael.freedman@oracle.com>:
>
>  FYI ... here are the preliminary thoughts related to Portlet 2.0Coordination 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)

Mime
View raw message