myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Freedman <michael.freed...@oracle.com>
Subject Re: About Portlets 2.0 and JSF
Date Thu, 06 Mar 2008 16:37:38 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
<h3>Portlet Coordination:&nbsp; Public Render Parameters</h3>
Summary:<br>
Idea is to map PRPs (and events) as alternative input to models.&nbsp;
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.&nbsp; 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.&nbsp; 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.&nbsp; The model mapping is accomplished via a new faces-config bridge
application-extension.&nbsp; The extension names a PRP and defines the
associated Faces EL it executes.&nbsp; Received PRPs have the associated set
accessor of this EL executed.&nbsp; The get accessors are called at end of
lifecycle to see if there are new values to be returned.&nbsp; It will works
as follows:<br>
<br>
PRPs received in an Action:<br>
<ol>
  <li>Activate FacesContext/Lifecycle/View/Restore bridge managed scope
(as usual).<br>
  </li>
  <li>Check request parameters for PRPs.&nbsp; 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.&nbsp; 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.</li>
  <li>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).&nbsp; This allows event
handler to trigger any needed model updates/recomputations.</li>
  <li>Wrap the request to hide PPRs from request(map) during further
processing -- note they are still available if call the
getPublicRenderParameters api directly.</li>
  <li>Call lifecycle.execute (ensures that the model values are pulled
into the view)</li>
  <li>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.&nbsp; Open question:&nbsp; only check those params that
were in the request or all mapped PPRs?&nbsp; I would argue that we do all
and for any that return null we delete the PPR from the response.&nbsp;&nbsp;</li>
</ol>
PRPs received in Events:<br>
<ol>
  <li>Activate FacesContext/Lifecycle/View/Restore bridge managed scope
(as usual). If no bridge request scope, create one. </li>
  <li>Check request parameters for PRPs.&nbsp; 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.&nbsp; 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.</li>
  <li>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).&nbsp; This allows event
handler to trigger any needed model updates/recomputations.</li>
  <li>Wrap the request to hide PPRs from request(map) during further
processing -- note they are still available if call the
getPublicRenderParameters api directly.</li>
  <li>Call the configured EventHandler passing the Event request (this
allows the EventHandler to push the payload into associated MBs).<br>
  </li>
  <li>Call lifecycle.execute (ensures that the model values are pulled
into the view)</li>
  <li>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.&nbsp; <br>
  </li>
</ol>
PPRs received in a Render:<br>
<ol>
  <li>Activate FacesContext/Lifecycle/View/Restore bridge managed scope
(as usual)<br>
  </li>
  <li>Check request parameters for PRPs.&nbsp; 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.&nbsp; 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.</li>
  <li>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).&nbsp; This allows event
handler to trigger any needed model updates/recomputations.</li>
  <li>Wrap the request to hide PPRs from request(map) during further
processing -- note they are still available if call the
getPublicRenderParameters api directly.</li>
  <li>Only if we processed any PRP, call lifecycle.execute (ensures
that the model values are pulled into the view)</li>
  <li>Call lifecycle.render</li>
  <li>Update VIEW_STATE_PARAM as usual<br>
  </li>
</ol>
PRPs received in Resource:<br>
<ol>
  <li>If there is a bridge managed scope, restore it but don't copy the
managed request attributes back into the request.&nbsp; Otherwise create a
scope (ID will have to be maintained in session until next full
action). </li>
  <li>Check request parameters for PRPs.&nbsp; 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.&nbsp; 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.</li>
  <li>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).&nbsp; This allows event
handler to trigger any needed model updates/recomputations.</li>
  <li>Wrap the request to hide PPRs from request(map) during further
processing -- note they are still available if call the
getPublicRenderParameters api directly.</li>
  <li>Call lifecycle.execute (besides processing the resource, ensures
that the model values are pulled into the view)</li>
  <li>Call lifecycle.render</li>
  <li>Save request scope into bridge request scope (use fixed up
VIEW_STATE_PARAM).&nbsp; The result should be a current reflection of
request scope data needed to render the current page entirely. </li>
</ol>
<br>
<h3>Portlet Coordination:&nbsp; Events</h3>
Summary: <br>
Call a portlet configured event handler to allow the client code to
directly push the event payload into the underlying models.&nbsp; This will
most likely use JSF EL to do the push.&nbsp; I.e. unlike PRPs the event
payloads are arbitrary/complex types hence its prohibitive for us to
use declarative mapping (at this point).&nbsp; 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:<br>
<br>
<ol>
  <li>Activate FacesContext/Lifecycle/View/Restore bridge managed scope
(as usual). If no bridge request scope, create one.<br>
  </li>
  <li>Check request parameters for PRPs.&nbsp; 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.&nbsp; 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.</li>
  <li>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).&nbsp; This allows event
handler to trigger any needed model updates/recomputations.</li>
  <li>Wrap the request to hide PPRs from request(map) during further
processing -- note they are still available if call the
getPublicRenderParameters api directly.</li>
  <li>Call the configured EventHandler passing the Event request (this
allows the EventHandler to push the payload into associated MBs).<br>
  </li>
  <li>Call lifecycle.execute (ensures that the model values are pulled
into the view)</li>
  <li>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.&nbsp; </li>
</ol>
<br>
<br>
Scott O'Bryan wrote:
<blockquote cite="mid47CDFA04.6010001@gmail.com" type="cite">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.&nbsp; We are
trying to get the 168 bridge out first.
  <br>
  <br>
Scott
  <br>
  <br>
Rogerio Pereira wrote:
  <br>
  <blockquote type="cite">Hi guys!
    <br>
    <br>
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.
    <br>
    <br>
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.
    <br>
    <br>
--&nbsp;<br>
Yours truly (Atenciosamente),
    <br>
    <br>
Rog&eacute;rio (_rogerio_)
    <br>
<a class="moz-txt-link-freetext" href="http://faces.eti.br">http://faces.eti.br</a>
    <br>
    <br>
"Fa&ccedil;a a diferen&ccedil;a! Ajude o seu pa&iacute;s a crescer, n&atilde;o
retenha
conhecimento, distribua e aprenda mais." (<a class="moz-txt-link-freetext" href="http://faces.eti.br/?p=45">http://faces.eti.br/?p=45</a>)
</blockquote>
  <br>
</blockquote>
</body>
</html>

Mime
View raw message