Mike is one of the speakers at JSF days, so be sure to catch him there.
Scott
Michael Freedman wrote:
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)
