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)
