AjaxPhaseListener

[Maksimenko Alexander <ma...@bird.cris.net>]

Hi!
I'm looking at AjaxPhaseListener. It looks great but I have some question -
at the end of the method I see
            context.responseComplete();
but as I understand all checks are performed before listener is invoked. 
So listener in render phase can't tell controller to skip rendering 
components. Or I was missed something? (I'm using 1.0.9 version)

Re: AjaxPhaseListener

[Craig McClanahan <cr...@gmail.com>]

On 7/14/05, Werner Punz <we...@gmx.at> wrote:
> Craig McClanahan wrote:
> > On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> >
> >
> >>Now in your opinion, should something like a phaselistener be used for
> >>remoting or would it be better to kind of replicate the faces-servlet?
> >
> >
> > There's a couple of different approaches that seem reasonable, but
> > it's also interesting to think about at least two "flavors" of
> > remoting as it relates to JSF:
> >
> > (a) The asynchronous call needs access to the JSF component
> >     tree for the page from which the call was submitted.
> >
> > (b) The asynchronous call is completely independent of the
> >     originating view, and should be a completely separate request.
> >
> > I think one of the BluePrints Catalog examples uses flavor (a), and it
> > does indeed use phase listeners ... but IIRC relies on a new JSF 1.2
> > feature that the UIViewRoot component can itself be a phase listener.
> > That would be useful in scenarios where you want to try to keep the
> > server side copy of the tree in sync with the changes that the client
> > side is making, or allow the server side handler to access state
> > information that was not in the asynchronous request.
> >
> Couldnt that be done in pre 1.2 as well, you just have to intercept
> after the server side tree is rebuilt. That however requires that the
> ajax request itself triggers the JSF lifecycle to its full extent until
> it is rendered and rendering can be intercepted?

I haven't looked at the code Ed did (on the BP catalog) for this in
detail ... but I seem to recall he ran into difficulties trying to do
what you describe.

In addition, I would think this whole idea would only be practical if
the JSF state was being saved on the server side ... wouldn't want to
have to include a humoungous hidden field with every AJAX request :-).

> To my sort of limited knowledge it should be possible.
> But as you said, I also think that keeping the server side tree in sync
> with the request is probably which will happen very seldomly, because
> most of the time ajax is more or less used sort of as a cheap data
> source infrastructure for javascript ui elements and normally a full
> refresh cycle is never triggered, but a full refresh most of the times
> leads to the next page or step in the page flow.
> 
> 

Yep.

Craig

Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

Maksimenko Alexander wrote:

> 
> Hi!
> I think that situations when user comes to the same page after several 
> ajax call are not very seldom (in my current project). I'm trying to 
> ajax data table component (paging,sorting). And it needs to change the 
> state of server side control because user can simply push refresh button 
> and it will get not up-to-date data in this case.
> 
Ok I was thinking in the scope of my last project and most stuff I had 
seen on the net... in this case you are definitely right and it is not 
very seldom.

Werner

Re: AjaxPhaseListener

[Maksimenko Alexander <ma...@bird.cris.net>]

Werner Punz wrote:

> But as you said, I also think that keeping the server side tree in 
> sync with the request is probably which will happen very seldomly, 
> because most of the time ajax is more or less used sort of as a cheap 
> data source infrastructure for javascript ui elements and normally a 
> full refresh cycle is never triggered, but a full refresh most of the 
> times leads to the next page or step in the page flow.


Hi!
I think that situations when user comes to the same page after several 
ajax call are not very seldom (in my current project). I'm trying to 
ajax data table component (paging,sorting). And it needs to change the 
state of server side control because user can simply push refresh button 
and it will get not up-to-date data in this case.

Re: Antwort: Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

mathias.werlitz@daimlerchrysler.com wrote:
> 
> A third thought:
> 
> Is it possible with the PhaseListener / java blueprint solution to 
> change the state / use a ajax component within a  UIData component that 
> iterates over its childs and manages their state?
> As far as I know this kind of components emulate a part of the request 
> cycle while iterating. I have no clue, but I worry that we run into some 
> problems there.
> 
I had another thought about some problems which might arise with 
asynchronous requests against the server.

You sometimes have some kind of post rendering do something situation 
which might be connected to a control. Now if you run into an 
asynchronous request which might trigger a rendering, you might get 
sideeffects which are unwanted, there has to be some kind of notificator
which has to be pushed into the request cycle which code which needs 
that kind of information can request so that it can behave according to 
the situation.

Up until now, this was not a problem, because there was one fixed cycle, 
but with ajax it is a completely different issue, because we sort of add 
an extra cycle in certain situations.

This notification stuff can be done easily by pushing a value into the 
request map.
What we probably need is a clearly defined value which can be requested 
in the request map, so that other components can react if there is a 
request out of the normal cycle.

Antwort: Re: AjaxPhaseListener

[ma...@daimlerchrysler.com]

A third thought:

Is it possible with the PhaseListener / java blueprint solution to change 
the state / use a ajax component within a  UIData component that iterates 
over its childs and manages their state?
As far as I know this kind of components emulate a part of the request 
cycle while iterating. I have no clue, but I worry that we run into some 
problems there.

Regards,

Mathias Werlitz

Antwort: Re: AjaxPhaseListener

[ma...@daimlerchrysler.com]

Well, my thoughts for the discussion.
I think manipulating the state of a component with an ajax request is very 
common.
Think of the tree2 as an ajax component. Basicly it is a server side tree2 
but the expand and collapse of the node would be triggered by a ajax 
request.
That would save much html traffic! But the state of the tree has to be 
kept in sync with every ajax request. There should be also a special 
rendering mode for the partial rendering of the child components and 
facets.

At the moment I can only use client side state saving because my 
application does support multiple windows. Therefor I use the x:saveState 
component for some beans.
I wonder if it is possible at all to keep the client state data in sync 
with the (partial) changed state on the server after a ajax request.

Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

Craig McClanahan wrote:
> On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> 
> 
>>Now in your opinion, should something like a phaselistener be used for
>>remoting or would it be better to kind of replicate the faces-servlet?
> 
> 
> There's a couple of different approaches that seem reasonable, but
> it's also interesting to think about at least two "flavors" of
> remoting as it relates to JSF:
> 
> (a) The asynchronous call needs access to the JSF component
>     tree for the page from which the call was submitted.
> 
> (b) The asynchronous call is completely independent of the
>     originating view, and should be a completely separate request.
> 
> I think one of the BluePrints Catalog examples uses flavor (a), and it
> does indeed use phase listeners ... but IIRC relies on a new JSF 1.2
> feature that the UIViewRoot component can itself be a phase listener. 
> That would be useful in scenarios where you want to try to keep the
> server side copy of the tree in sync with the changes that the client
> side is making, or allow the server side handler to access state
> information that was not in the asynchronous request.
> 
Couldnt that be done in pre 1.2 as well, you just have to intercept 
after the server side tree is rebuilt. That however requires that the 
ajax request itself triggers the JSF lifecycle to its full extent until 
it is rendered and rendering can be intercepted?
To my sort of limited knowledge it should be possible.
But as you said, I also think that keeping the server side tree in sync 
with the request is probably which will happen very seldomly, because 
most of the time ajax is more or less used sort of as a cheap data 
source infrastructure for javascript ui elements and normally a full 
refresh cycle is never triggered, but a full refresh most of the times 
leads to the next page or step in the page flow.

Re: AjaxPhaseListener

[Craig McClanahan <cr...@gmail.com>]

On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:

> Now in your opinion, should something like a phaselistener be used for
> remoting or would it be better to kind of replicate the faces-servlet?

There's a couple of different approaches that seem reasonable, but
it's also interesting to think about at least two "flavors" of
remoting as it relates to JSF:

(a) The asynchronous call needs access to the JSF component
    tree for the page from which the call was submitted.

(b) The asynchronous call is completely independent of the
    originating view, and should be a completely separate request.

I think one of the BluePrints Catalog examples uses flavor (a), and it
does indeed use phase listeners ... but IIRC relies on a new JSF 1.2
feature that the UIViewRoot component can itself be a phase listener. 
That would be useful in scenarios where you want to try to keep the
server side copy of the tree in sync with the changes that the client
side is making, or allow the server side handler to access state
information that was not in the asynchronous request.

To me, flavor (b) looks like it'll be a lot more common, and when you
*don't* need access to the component tree it should require less
overhead.  Shale's remoting support currently implements this but with
a twist ... we go ahead and create a FacesContext for the asynchronous
request, just like FacesServlet does for regular requests (Shale does
it in a filter, but it could just as easily be a second servlet).  It
doesn't actually run the JSF lifecycle on the asynchronous request
(although I'm toying with a custom Lifecycle implementation just for
remoting).  But, the benefit of having a FacesContext around is that
the server side handler code can evaluate value binding and method
binding expressions programatically.  Among other things, that means
the handler can leverage managed beans and the dependency injection
paradigm you get from them.

The code that actually does this is in
"org.apache.shale.remote.RemoteCommand" and the code that sets up the
FacesContext will look suspiciously like the analogous code in
FacesServlet, since it is doing pretty much the same thing :-).

> regards,
> 
> Martin

Craig

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

Now in your opinion, should something like a phaselistener be used for
remoting or would it be better to kind of replicate the faces-servlet?

regards,

Martin

On 7/14/05, Craig McClanahan <cr...@gmail.com> wrote:
> There is indeed a partial ordering specified in Section 10.3.2
> (META-INF/faces-config.xml from jar files, then look at the
> javax.faces.CONFIG_FILES context init parameter, then
> WEB-INF/faces-config.xml if it exists) ... but that doesn't guarantee
> you the ordering of listener calls.  Even if it tried, you are still
> not out of the woods -- for example, the order that JAR files will be
> processed depends on the implementation of the app server's class
> loader.
> 
> In general, think of phase events and listeners as a way to do things
> for the *application* (i.e. the code that actually runs during a
> phase) -- they should not have ordering dependencies between each
> other.  This is a general principle for events and listeners
> throughout the Java model (for example, PropertyChangeEvents from a
> JavaBean), where the order of event notifications is not
> deterministic.
> 
> Craig
> 
> 
> On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > This is - by the way- the sequence of reading config files in MyFaces:
> >
> >             feedStandardConfig();
> >             feedMetaInfServicesFactories();
> >             feedJarFileConfigurations();
> >             feedContextSpecifiedConfig();
> >             feedWebAppConfig();
> >
> > regards,
> >
> > Martin
> >
> > On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > Yes,
> > >
> > > you are right... It would be even nicer to be able to exactly define
> > > the sequence.
> > >
> > > Still, I don't think that using a separate servlet here is the way to
> > > go - I mean why has the concept of a phase listener been developed? We
> > > should rather fix the problems we have with this thing instead.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 7/14/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > > > On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > > I think they do execute in a particular order, i.e. the order the
> > > > > faces-config files are loaded.
> > > >
> > > > They are called in a particular order for a particular implemention, for sure.
> > > > Is it specified in the spec, though? (Pure ignorance -- maybe it is).
> > > > Is the order the faces-config files are loaded from jar files known?
> > > >
> > > > > With that the dataTable phaselistener would of course be situated
> > > > > ahead of your phaseListener.
> > > > >
> > > > > No if the AJAX phase listener makes it into the framework, it will be
> > > > > the first one to be called - which should be quite reasonable.
> > > >
> > > > If it's the first one called, does this mean it'd potentially access
> > > > application data outside of a phase? (before the application's before
> > > > phase listener is executed, and likewise for after)
> > > >
> > > > It's too bad the JSF spec doesn't provide some way to insure that
> > > > application-level phase listeners are triggered, then "framework"
> > > > component phase listeners.   I do understand the difficulties between
> > > > distinguishing between them, though.
> > > >
> > > > Maybe just insuring that any faces-config listeners in
> > > > WEB-INF/faces-config.xml (or otherwise specified in web.xml) were
> > > > executed before faces-config.xml files in jars would be helpful.
> > > > Probably useless conjecturing, though.
> > > >
> > >
> >
>

Re: AjaxPhaseListener

[Craig McClanahan <cr...@gmail.com>]

On 7/14/05, Werner Punz <we...@gmx.at> wrote:
> Craig McClanahan wrote:
> > There is indeed a partial ordering specified in Section 10.3.2
> > (META-INF/faces-config.xml from jar files, then look at the
> > javax.faces.CONFIG_FILES context init parameter, then
> > WEB-INF/faces-config.xml if it exists) ... but that doesn't guarantee
> > you the ordering of listener calls.  Even if it tried, you are still
> > not out of the woods -- for example, the order that JAR files will be
> > processed depends on the implementation of the app server's class
> > loader.
> >
> > In general, think of phase events and listeners as a way to do things
> > for the *application* (i.e. the code that actually runs during a
> > phase) -- they should not have ordering dependencies between each
> > other.  This is a general principle for events and listeners
> > throughout the Java model (for example, PropertyChangeEvents from a
> > JavaBean), where the order of event notifications is not
> > deterministic.
> >
> Does the ordering really matter in the case of ajax, think of the whole
> ajax cycle as being an extra cycle out of the jsf scope, because all the
> ajax requests resemble more webservices than anything else, you simply
> call something on the server fetch the data and do something with it on
> the client. I think going the phase listener route in this case is
> viable although it might be slower than going the servlet route.
> 

I might be out of context, but I thought I saw a comment where someone
wanted to create and cache some data in one phase listener, then
process it in another phase listener for the same event.  That's what
you cannot count on being able to do (although you could count on
being able to process it in a listener for a later phase).

Howver, even if order were determinsitic, I would never use phase
listeners for my type (b) remoting calls, where the server side logic
need not have access to the component tree for the client that
submitted the request.  Instead, I'd either:

* Use a completely separate filter or servlet (i.e. what Shale does right now).

* Regsiter an alternate JSF lifecycle that sets up a FacesContext,
  calls an execute() type method on the handler, then calls a
  render() type method on the handler.  (I'm noodling on this one
  but haven't checked any code in yet).

Craig

Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

Craig McClanahan wrote:
> There is indeed a partial ordering specified in Section 10.3.2
> (META-INF/faces-config.xml from jar files, then look at the
> javax.faces.CONFIG_FILES context init parameter, then
> WEB-INF/faces-config.xml if it exists) ... but that doesn't guarantee
> you the ordering of listener calls.  Even if it tried, you are still
> not out of the woods -- for example, the order that JAR files will be
> processed depends on the implementation of the app server's class
> loader.
> 
> In general, think of phase events and listeners as a way to do things
> for the *application* (i.e. the code that actually runs during a
> phase) -- they should not have ordering dependencies between each
> other.  This is a general principle for events and listeners
> throughout the Java model (for example, PropertyChangeEvents from a
> JavaBean), where the order of event notifications is not
> deterministic.
> 
Does the ordering really matter in the case of ajax, think of the whole 
ajax cycle as being an extra cycle out of the jsf scope, because all the 
ajax requests resemble more webservices than anything else, you simply 
call something on the server fetch the data and do something with it on 
the client. I think going the phase listener route in this case is 
viable although it might be slower than going the servlet route.

Re: AjaxPhaseListener

[Craig McClanahan <cr...@gmail.com>]

There is indeed a partial ordering specified in Section 10.3.2
(META-INF/faces-config.xml from jar files, then look at the
javax.faces.CONFIG_FILES context init parameter, then
WEB-INF/faces-config.xml if it exists) ... but that doesn't guarantee
you the ordering of listener calls.  Even if it tried, you are still
not out of the woods -- for example, the order that JAR files will be
processed depends on the implementation of the app server's class
loader.

In general, think of phase events and listeners as a way to do things
for the *application* (i.e. the code that actually runs during a
phase) -- they should not have ordering dependencies between each
other.  This is a general principle for events and listeners
throughout the Java model (for example, PropertyChangeEvents from a
JavaBean), where the order of event notifications is not
deterministic.

Craig


On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> This is - by the way- the sequence of reading config files in MyFaces:
> 
>             feedStandardConfig();
>             feedMetaInfServicesFactories();
>             feedJarFileConfigurations();
>             feedContextSpecifiedConfig();
>             feedWebAppConfig();
> 
> regards,
> 
> Martin
> 
> On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes,
> >
> > you are right... It would be even nicer to be able to exactly define
> > the sequence.
> >
> > Still, I don't think that using a separate servlet here is the way to
> > go - I mean why has the concept of a phase listener been developed? We
> > should rather fix the problems we have with this thing instead.
> >
> > regards,
> >
> > Martin
> >
> > On 7/14/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > I think they do execute in a particular order, i.e. the order the
> > > > faces-config files are loaded.
> > >
> > > They are called in a particular order for a particular implemention, for sure.
> > > Is it specified in the spec, though? (Pure ignorance -- maybe it is).
> > > Is the order the faces-config files are loaded from jar files known?
> > >
> > > > With that the dataTable phaselistener would of course be situated
> > > > ahead of your phaseListener.
> > > >
> > > > No if the AJAX phase listener makes it into the framework, it will be
> > > > the first one to be called - which should be quite reasonable.
> > >
> > > If it's the first one called, does this mean it'd potentially access
> > > application data outside of a phase? (before the application's before
> > > phase listener is executed, and likewise for after)
> > >
> > > It's too bad the JSF spec doesn't provide some way to insure that
> > > application-level phase listeners are triggered, then "framework"
> > > component phase listeners.   I do understand the difficulties between
> > > distinguishing between them, though.
> > >
> > > Maybe just insuring that any faces-config listeners in
> > > WEB-INF/faces-config.xml (or otherwise specified in web.xml) were
> > > executed before faces-config.xml files in jars would be helpful.
> > > Probably useless conjecturing, though.
> > >
> >
>

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

This is - by the way- the sequence of reading config files in MyFaces:

            feedStandardConfig();
            feedMetaInfServicesFactories();
            feedJarFileConfigurations();
            feedContextSpecifiedConfig();
            feedWebAppConfig();

regards,

Martin

On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> Yes,
> 
> you are right... It would be even nicer to be able to exactly define
> the sequence.
> 
> Still, I don't think that using a separate servlet here is the way to
> go - I mean why has the concept of a phase listener been developed? We
> should rather fix the problems we have with this thing instead.
> 
> regards,
> 
> Martin
> 
> On 7/14/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > I think they do execute in a particular order, i.e. the order the
> > > faces-config files are loaded.
> >
> > They are called in a particular order for a particular implemention, for sure.
> > Is it specified in the spec, though? (Pure ignorance -- maybe it is).
> > Is the order the faces-config files are loaded from jar files known?
> >
> > > With that the dataTable phaselistener would of course be situated
> > > ahead of your phaseListener.
> > >
> > > No if the AJAX phase listener makes it into the framework, it will be
> > > the first one to be called - which should be quite reasonable.
> >
> > If it's the first one called, does this mean it'd potentially access
> > application data outside of a phase? (before the application's before
> > phase listener is executed, and likewise for after)
> >
> > It's too bad the JSF spec doesn't provide some way to insure that
> > application-level phase listeners are triggered, then "framework"
> > component phase listeners.   I do understand the difficulties between
> > distinguishing between them, though.
> >
> > Maybe just insuring that any faces-config listeners in
> > WEB-INF/faces-config.xml (or otherwise specified in web.xml) were
> > executed before faces-config.xml files in jars would be helpful.
> > Probably useless conjecturing, though.
> >
>

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

Yes,

you are right... It would be even nicer to be able to exactly define
the sequence.

Still, I don't think that using a separate servlet here is the way to
go - I mean why has the concept of a phase listener been developed? We
should rather fix the problems we have with this thing instead.

regards,

Martin

On 7/14/05, Mike Kienenberger <mk...@gmail.com> wrote:
> On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> > I think they do execute in a particular order, i.e. the order the
> > faces-config files are loaded.
> 
> They are called in a particular order for a particular implemention, for sure.
> Is it specified in the spec, though? (Pure ignorance -- maybe it is).
> Is the order the faces-config files are loaded from jar files known?
> 
> > With that the dataTable phaselistener would of course be situated
> > ahead of your phaseListener.
> >
> > No if the AJAX phase listener makes it into the framework, it will be
> > the first one to be called - which should be quite reasonable.
> 
> If it's the first one called, does this mean it'd potentially access
> application data outside of a phase? (before the application's before
> phase listener is executed, and likewise for after)
> 
> It's too bad the JSF spec doesn't provide some way to insure that
> application-level phase listeners are triggered, then "framework"
> component phase listeners.   I do understand the difficulties between
> distinguishing between them, though.
> 
> Maybe just insuring that any faces-config listeners in
> WEB-INF/faces-config.xml (or otherwise specified in web.xml) were
> executed before faces-config.xml files in jars would be helpful.
> Probably useless conjecturing, though.
>

Fwd: AjaxPhaseListener

[Mike Kienenberger <mk...@gmail.com>]

On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> I think they do execute in a particular order, i.e. the order the
> faces-config files are loaded.

They are called in a particular order for a particular implemention, for sure.
Is it specified in the spec, though? (Pure ignorance -- maybe it is).
Is the order the faces-config files are loaded from jar files known?

> With that the dataTable phaselistener would of course be situated
> ahead of your phaseListener.
>
> No if the AJAX phase listener makes it into the framework, it will be
> the first one to be called - which should be quite reasonable.

If it's the first one called, does this mean it'd potentially access
application data outside of a phase? (before the application's before
phase listener is executed, and likewise for after)

It's too bad the JSF spec doesn't provide some way to insure that
application-level phase listeners are triggered, then "framework"
component phase listeners.   I do understand the difficulties between
distinguishing between them, though.

Maybe just insuring that any faces-config listeners in
WEB-INF/faces-config.xml (or otherwise specified in web.xml) were
executed before faces-config.xml files in jars would be helpful.
Probably useless conjecturing, though.

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

I think they do execute in a particular order, i.e. the order the
faces-config files are loaded.

With that the dataTable phaselistener would of course be situated
ahead of your phaseListener.

No if the AJAX phase listener makes it into the framework, it will be
the first one to be called - which should be quite reasonable.

regards,

Martin

On 7/14/05, Mike Kienenberger <mk...@gmail.com> wrote:
> While that's true, phase listeners don't get triggered in any particular order.
> 
> I had problems with the older DataTable because it accessed my
> application data from a phase listener, and the data it accessed was
> only available after my application's phase listener ran.
> 
> Not having examine the code, it could very well be a moot point in
> this instance as the listener may never access application data.
> 
> I'd rather see it done as a servlet if it could be done that way.   As
> for the configuration, well, you're gonna have to add in a config line
> for the myfaces extensions anyway.
> 
> Being a novice JSF user, give my thoughts only the minor consideration
> that they're due, and don't beat me up too badly if I'm saying
> something stupid
>  :)
> 
> -Mike
> 
> 
> On 7/14/05, Werner Punz <we...@gmx.at> wrote:
> > Maksimenko Alexander wrote:
> > > Hi!
> > > I'm looking at AjaxPhaseListener. It looks great but I have some question -
> > > at the end of the method I see
> > >            context.responseComplete();
> > > but as I understand all checks are performed before listener is invoked.
> > > So listener in render phase can't tell controller to skip rendering
> > > components. Or I was missed something? (I'm using 1.0.9 version)
> > >
> > A phase listener is triggerted whenever a request comes in, what ajax
> > does is to trigger requests without performing a page refresh, thus the
> > whole phase listener chain is called every time an ajax request goes
> > against the server.
> >
> > So what happens? the user does something xmlhttp triggers a request
> > against the server, the phase listener is triggered performs its
> > functions, the result is given back and the client does something with it.
> >
> > No refresh cycle is performed. The Phase listener is sort of used as a
> > request interceptor, kind of like a servlet or servlet filter.
> >
> > Hope this helps in understanding what happens. You pretty much can do
> > the same by using a servlet, but that way you need an extra entry in the
> > web.xml file a phase listener can be defined simply by adding an entry
> > in one of the faces-configs, thus it can be delivered automatically with
> > a component pack.
> >
> >
> >
> >
>

Re: AjaxPhaseListener

[Mike Kienenberger <mk...@gmail.com>]

While that's true, phase listeners don't get triggered in any particular order.

I had problems with the older DataTable because it accessed my
application data from a phase listener, and the data it accessed was
only available after my application's phase listener ran.

Not having examine the code, it could very well be a moot point in
this instance as the listener may never access application data.

I'd rather see it done as a servlet if it could be done that way.   As
for the configuration, well, you're gonna have to add in a config line
for the myfaces extensions anyway.

Being a novice JSF user, give my thoughts only the minor consideration
that they're due, and don't beat me up too badly if I'm saying
something stupid
 :)

-Mike


On 7/14/05, Werner Punz <we...@gmx.at> wrote:
> Maksimenko Alexander wrote:
> > Hi!
> > I'm looking at AjaxPhaseListener. It looks great but I have some question -
> > at the end of the method I see
> >            context.responseComplete();
> > but as I understand all checks are performed before listener is invoked.
> > So listener in render phase can't tell controller to skip rendering
> > components. Or I was missed something? (I'm using 1.0.9 version)
> >
> A phase listener is triggerted whenever a request comes in, what ajax
> does is to trigger requests without performing a page refresh, thus the
> whole phase listener chain is called every time an ajax request goes
> against the server.
> 
> So what happens? the user does something xmlhttp triggers a request
> against the server, the phase listener is triggered performs its
> functions, the result is given back and the client does something with it.
> 
> No refresh cycle is performed. The Phase listener is sort of used as a
> request interceptor, kind of like a servlet or servlet filter.
> 
> Hope this helps in understanding what happens. You pretty much can do
> the same by using a servlet, but that way you need an extra entry in the
> web.xml file a phase listener can be defined simply by adding an entry
> in one of the faces-configs, thus it can be delivered automatically with
> a component pack.
> 
> 
> 
>

Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

Maksimenko Alexander wrote:
> Hi!
> I'm looking at AjaxPhaseListener. It looks great but I have some question -
> at the end of the method I see
>            context.responseComplete();
> but as I understand all checks are performed before listener is invoked. 
> So listener in render phase can't tell controller to skip rendering 
> components. Or I was missed something? (I'm using 1.0.9 version)
> 
A phase listener is triggerted whenever a request comes in, what ajax 
does is to trigger requests without performing a page refresh, thus the 
whole phase listener chain is called every time an ajax request goes 
against the server.

So what happens? the user does something xmlhttp triggers a request 
against the server, the phase listener is triggered performs its 
functions, the result is given back and the client does something with it.

No refresh cycle is performed. The Phase listener is sort of used as a 
request interceptor, kind of like a servlet or servlet filter.

Hope this helps in understanding what happens. You pretty much can do 
the same by using a servlet, but that way you need an extra entry in the 
web.xml file a phase listener can be defined simply by adding an entry 
in one of the faces-configs, thus it can be delivered automatically with 
a component pack.

Re: AjaxPhaseListener

[Werner Punz <we...@gmx.at>]

Ah sorry I misunderstood the original post.
Martin the way I see it is, that you can use some kind of uri
filter in the PhaseListener which treats the request as a single 
component request.

That way you do not run through the entire page for rendering but only 
through the component rendering, which is acceptable.


Werner


Martin Marinschek wrote:
> You are right, this is useless ;) 
> 
> ... which will mean the rendering will always occur.
> 
> Do you have any workaround for that?
> 
> regards,
> 
> Martin
> 
> On 7/14/05, Maksimenko Alexander <ma...@bird.cris.net> wrote:
> 
>>Hi!
>>I'm looking at AjaxPhaseListener. It looks great but I have some question -
>>at the end of the method I see
>>            context.responseComplete();
>>but as I understand all checks are performed before listener is invoked.
>>So listener in render phase can't tell controller to skip rendering
>>components. Or I was missed something? (I'm using 1.0.9 version)
>>
> 
> 

Re: AjaxPhaseListener

[Maksimenko Alexander <ma...@bird.cris.net>]

Martin Marinschek wrote:

>dooh..
>
>workaround would be to have an after invoke application phase
>listener, of course.
>
>I will change that!
>  
>

Yes I think about the same workaround
Thanks for answer it saves me from long debug session ;)

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

dooh..

workaround would be to have an after invoke application phase
listener, of course.

I will change that!

regards,

Martin

On 7/14/05, Martin Marinschek <ma...@gmail.com> wrote:
> You are right, this is useless ;)
> 
> ... which will mean the rendering will always occur.
> 
> Do you have any workaround for that?
> 
> regards,
> 
> Martin
> 
> On 7/14/05, Maksimenko Alexander <ma...@bird.cris.net> wrote:
> > Hi!
> > I'm looking at AjaxPhaseListener. It looks great but I have some question -
> > at the end of the method I see
> >             context.responseComplete();
> > but as I understand all checks are performed before listener is invoked.
> > So listener in render phase can't tell controller to skip rendering
> > components. Or I was missed something? (I'm using 1.0.9 version)
> >
>

Re: AjaxPhaseListener

[Martin Marinschek <ma...@gmail.com>]

You are right, this is useless ;) 

... which will mean the rendering will always occur.

Do you have any workaround for that?

regards,

Martin

On 7/14/05, Maksimenko Alexander <ma...@bird.cris.net> wrote:
> Hi!
> I'm looking at AjaxPhaseListener. It looks great but I have some question -
> at the end of the method I see
>             context.responseComplete();
> but as I understand all checks are performed before listener is invoked.
> So listener in render phase can't tell controller to skip rendering
> components. Or I was missed something? (I'm using 1.0.9 version)
>