[shale] Custom Lifecylce vs. Phase Listener

[Sean Schofield <se...@gmail.com>]

Craig,

I've been thinking about a post you made on myfaces-dev a few months
ago about Ajax and phase listeners.  You mentioned that in addition to
the remoting support that you have now you were considering a custom
LifeCycle object for remoting.  I don't know much about this aspect of
JSF so now I'm looking into that.

One question I have is why Shale uses the phase listener approach
instead of a custom lifecycle?  You are essentially adding on phases
to the lifecylce so why not use this feature of JSF?  Is it because
there was no open source JSF implementation at the time?  It seems
like you could have ShaleApplicationServlet instead of
ShaleApplicationFilter + FacesServlet.

Also, I was wondering abut how the proposed lifecylce for remoting
might work.  One problem I can forsee is that you would have to use
the same lifecylce instance for every request (instead of two
lifecylces: one regular, and one abbreviated.)  My reasoning is that
the FacesContext is lifecylce dependent.  Of course you could skip
certain steps in the new lifecycle depending on the nature of the
request and you would effectively be making it abbreviated.  Do I have
this right?

If you are still interested in working on this I will find time to
help out.  There are probably also guys on the myfaces team who would
be willing to help.

sean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Custom Lifecylce vs. Phase Listener

[Craig McClanahan <cr...@apache.org>]

On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
>
> Craig,
>
> I've been thinking about a post you made on myfaces-dev a few months
> ago about Ajax and phase listeners. You mentioned that in addition to
> the remoting support that you have now you were considering a custom
> LifeCycle object for remoting. I don't know much about this aspect of
> JSF so now I'm looking into that.


The original motiviation for this was to support a FacesContext object on
remote requests, so that you could use value binding and method binding
expressions when creating the response. It turns out that was possible
without creating a separate Lifecycle object, so it may not be necessary.

Note that, with the current remoting support in Shale, the remote request
does *not* have access to the component tree state for the page from which
the request was submitted. I believe that there will be two common use cases
for Ajax requests in a JSF world:

* Components that want to do asynchronous requests, make
dynamic modifications to the client side DOM, *and* keep the
server side state of the JSF components in sync.

* Components that need to go to the server for extra data (such
as a code completion widget) or to perform database validations
(on a create user form, is this username already in use by
someone else), where you're not modifying the client side DOM
nor worrying about the server side state of the components.

The latter scenario also supports non-JSF based Ajax functionality, as well
as a possible future world where the controller moves into the client (i.e.
"write the entire application in one page" sorts of scenarios). In a JSF
centric world, it's too easy to forget that, IMHO at least, this represents
the majority of use cases :-).

One question I have is why Shale uses the phase listener approach
> instead of a custom lifecycle? You are essentially adding on phases
> to the lifecylce so why not use this feature of JSF? Is it because
> there was no open source JSF implementation at the time? It seems
> like you could have ShaleApplicationServlet instead of
> ShaleApplicationFilter + FacesServlet.


One of the knocks against JSF that you sometimes hear is that it is page
centric, not request centric. I used a filter so that you can still gain
control *before* JSF does -- even before FacesServlet gets involved -- and
do application-level processing like "if the user is not logged in, force
him/her to the login page".

Also, I was wondering abut how the proposed lifecylce for remoting
> might work. One problem I can forsee is that you would have to use
> the same lifecylce instance for every request (instead of two
> lifecylces: one regular, and one abbreviated.) My reasoning is that
> the FacesContext is lifecylce dependent. Of course you could skip
> certain steps in the new lifecycle depending on the nature of the
> request and you would effectively be making it abbreviated. Do I have
> this right?


Remembering that the FacesContext for the remote request wouldn't have
access to the component tree for the page from which the request came, the
two methods defined in the Lifecycle API would want to have the following
semantics:

* execute() -- create a Context (in the Commons Chain sense)
and invoke the processing chain for the submitted-to URL.
One could either dispense with phases entirely, or we might
consider invoking a chain for each phase for semantic
similarity to how JSF's phases work for form submits.

* render() -- invoke an appropriate chain to generate the
response XML or whatever.

Of particular interest would be the ability to use JSF's standard
ResponseWriter machinery, if you prefer to render your XML with Java code.
Then, we could dispense with Shale's semi-dupication of this (
org.apache.shale.remote.ResponseWrapper). It may be that the current
functionality makes this possible already; just haven't had time to play
with it yet.

If you are still interested in working on this I will find time to
> help out. There are probably also guys on the myfaces team who would
> be willing to help.


That would be cool ... although it looks like MyFaces already has a strategy
in place for the first use case described above (where the Ajax request
*does* want access to the component state of the page). It would be nice if
that were packaged in such a way that it could be used on top of other JSF
implementations too.

sean


Craig