Ajax lifecircle integration

[Volker Weber <us...@weber-oldenburg.de>]

Hi,

during working on ajaxifying some tobago components i came over some
issues which i like to discuss here.

Starting with adding inputSuggestAjax functionality to the tc:in
component everything goes well with the current sandbox approach running
the AjaxPhaseListener after InvokeApplication.

My next step was ajaxifying the server side tab switching of tabgroup.
For this in need to add the tabs content values into the request to
preserve them in the view. Now the problem of validation and updateModel
occurs: If a validation error occurs, then the rest of lifcircle
(including AjaxPhaseListener) is skipped and the whole page is rendered
as response where only the content of one tab was expected on client side.
I decided to move the Listener to after ApplyRequestValues phase. And
leave the responsibility for executing other phases (like updateModel
and Validation) to the ajaxifyed component(e.g. to the programmer of
this component).

Some weeks ago here was the proposal to replace the current procedure in
AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
by something like processAjax() invoked on uiViewRoot. In my opinion
this makes sense because there could be more to do than just rendering.


Another problem are component specific resources like javascript and
style files (*.js and *.css). Currently they are added to the header
only if they are needed after rendering the page content. In tomahawk by
the ExtensionFilter, in tobago by the PageRenderer after the content was
rendered into a buffer. This is not possible if they are rendered by a
tabswitching ajax request, because the (html) header is not rendered
then. There are two solutions:
1) render always all possible resources into the header (I don' like
   this)
2) load these resources via clientside scripting (This is what i
   prefer, but i'm not sure about the best way to do this)


Any thougths about the best way to handle these problems?

regards,

   Volker

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: Ajax lifecircle integration

[Grant Smith <wo...@gmail.com>]

We might also want to consider using the Taconite library, which seems more
cross-browser friendly than using innerhtml.


--
Grant Smith

Re: Ajax lifecircle integration

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

We should also take a look at what Craig has come up with for Shale. 
I'm not sure whether he as any code (haven't looked yet) down but I
know he has been giving a lot of thought to hwo to incorporate Ajax
into JSF.

This is a good reason to keep any Ajax components in the sandbox for a
while until we get this sorted out.  It will be easier on our users to
come up with something really good and get all of the kinks worked out
before they start relying on our approach.

I am still thinking the processAjax() method or whatever would be a
good idea.  I'll need to re-read some of the posts from several months
ago concerning this topic because there seem to be a lot of good ideas
on the subject.

sean

On 11/5/05, Travis Reeder <tr...@gmail.com> wrote:
> This might be somewhat related to what you're trying to do, but I've added
> the AjaxDecodePhaseListener that gets kicked off before the apply request
> values phase so that it can validate and update for that single component.
> If an error occurs such as a validation error, the error is sent back in the
> ajax request so that the message can be shown to the user.  You can see the
> initial results of this on the Form Fields updated dynamically through ajax
> examples by putting in an invalid date on the date text field.
>
> Travis
>
> On 11/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > Volker,  I don't have any answers for you.
> >
> > However, by moving the phase listener to after the apply request
> > values phase, you're still going to have the same issues with
> > validation that you had with InvokeApplication since end-users might
> > specify components as immediate=true.
> >
> > On 11/5/05, Volker Weber
> <us...@weber-oldenburg.de> wrote:
> > > Hi,
> > >
> > > during working on ajaxifying some tobago components i came over some
> > > issues which i like to discuss here.
> > >
> > > Starting with adding inputSuggestAjax functionality to the tc:in
> > > component everything goes well with the current sandbox approach running
> > > the AjaxPhaseListener after InvokeApplication.
> > >
> > > My next step was ajaxifying the server side tab switching of tabgroup.
> > > For this in need to add the tabs content values into the request to
> > > preserve them in the view. Now the problem of validation and updateModel
> > > occurs: If a validation error occurs, then the rest of lifcircle
> > > (including AjaxPhaseListener) is skipped and the whole page is rendered
> > > as response where only the content of one tab was expected on client
> side.
> > > I decided to move the Listener to after ApplyRequestValues phase. And
> > > leave the responsibility for executing other phases (like updateModel
> > > and Validation) to the ajaxifyed component(e.g. to the programmer of
> > > this component).
> > >
> > > Some weeks ago here was the proposal to replace the current procedure in
> > > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> > > by something like processAjax() invoked on uiViewRoot. In my opinion
> > > this makes sense because there could be more to do than just rendering.
> > >
> > >
> > > Another problem are component specific resources like javascript and
> > > style files (*.js and *.css). Currently they are added to the header
> > > only if they are needed after rendering the page content. In tomahawk by
> > > the ExtensionFilter, in tobago by the PageRenderer after the content was
> > > rendered into a buffer. This is not possible if they are rendered by a
> > > tabswitching ajax request, because the (html) header is not rendered
> > > then. There are two solutions:
> > > 1) render always all possible resources into the header (I don' like
> > >    this)
> > > 2) load these resources via clientside scripting (This is what i
> > >    prefer, but i'm not sure about the best way to do this)
> > >
> > >
> > > Any thougths about the best way to handle these problems?
> > >
> > > regards,
> > >
> > >    Volker
> > >
> > > --
> > > Don't answer to From: address!
> > > Mail to this account are droped if not recieved via mailinglist.
> > > To contact me direct create the mail address by
> > > concatenating my forename to my senders domain.
> > >
> > >
> >
>
>

Re: Ajax lifecircle integration

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

Ok,

so you are saying that memory allocation is more a problem than CPU time?

Cause we currently had a user doing a load test with 100 concurrent
users, and client side state saving seemed to result in an
indefinitely slow result due to the CPU time allocated... memory
allocation was no problem for her.

regards,

Martin

On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> Martin,
>
> If you look at any postback, the areas that chew up time are:
>
> 1. Recreating the component tree
> 2. Going through the full lifecycle
> 3. Saving the component tree
> 4. Rendering the response
>
> If you want a hyper-efficient async, granular JSF response, you
> have to tackle each of these, both in terms of raw CPU and
> memory allocation (the latter more important when you look
> at multi-user scalability).
>
> Each of these has its own trickiness, and is harder than it
> seems at first. :)  I really have to start blogging;  each of
> these is like a separate article...
>
> So, yes, optimizing the lifecycle is a good start, but it's not
> a complete solution.
>
> -- Adam
>
>
>
> On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Sounds promising to me!
> >
> > Even though from the perfomance tests that have been posted to the
> > mailing list a while ago, it doesn't look like going through the
> > lifecycle is the big problem - but rather restoring/saving the state
> > if you use client-side state saving.
> >
> > Adam, can you confirm that from your experience with ADF Faces?
> >
> > regards,
> >
> > Martin
> >
> > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > Thanks.  That confirms what I suspected (as far as being able to have
> > > a custom lifecycle using an init param.)
> > >
> > > So the suggestion would be in MyFaces to create a new custom lifecycle
> > > that included the default lifecycle and other optional steps.  With
> > > the right URL or request parameter  you would use the nonstandard
> > > phases (or jump around in a non-standard way).  Otherwise you would
> > > follow the standard steps only.  By default (without the special
> > > servlet context init parameter) you would get the default lifecycle.
> > > Would this work?
> > >
> > > sean
> > >
> > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > You can configure FacesServlet to have a custom lifecycle using
> > > > a servlet context init parameter.  But you can't, say, have two
> > > > FacesServlets each running a different lifecycle - one standard,
> > > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > > you can configure the lifecycle ID as a servlet config
> > > > parameter, not just a context init parameter.
> > > >
> > > > -- Adam
> > > >
> > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > I think Craig was referring to the *current* ability to configure a
> > > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > > Can you clarify this some?
> > > > >
> > > > > sean
> > > > >
> > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > >
> > > > > > > For the type (a) components (where you need the component tree and
> > > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > > but it sounds interesting.
> > > > > > >
> > > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > > still applies but that you can also configure it with a specialized
> > > > > > > lifecycle.
> > > > > >
> > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > > EG for quite awhile now.)
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

[Travis Reeder <tr...@gmail.com>]

I like the storing the components in a map idea. If we did that, we could
actually use the current PhaseListener way of doing it, but move the
AjaxDecodePhaseListener to occur before the Restore View phase, apply the
lifecycle to the affected components, and then call renderResponse() to
allow the ajax response to be sent. Or better yet, call responseComplete and
just execute the renderers in the initial PhaseListener. This would
completely skip the entire lifecycle on every other component and wouldn't
be too far off from the current strategy.

Travis

On 11/16/05, Sean Schofield <se...@gmail.com> wrote:
>
> One idea I had was that it would be nice if you could jump right to a
> specific component without restoring the whole tree. In other words
> you have async post for component with id of "foo" and you can grab
> that directly out of a session map and perform the full lifecylce (but
> just on that component.)
>
> If the component had children you would process them as well. Just
> some random thoughts. I'd be interested in hearing other ideas.
> (I'll do some research on the blogs and forums and see what others
> have suggested.)
>
> sean
>
> On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> > Martin,
> >
> > If you look at any postback, the areas that chew up time are:
> >
> > 1. Recreating the component tree
> > 2. Going through the full lifecycle
> > 3. Saving the component tree
> > 4. Rendering the response
> >
> > If you want a hyper-efficient async, granular JSF response, you
> > have to tackle each of these, both in terms of raw CPU and
> > memory allocation (the latter more important when you look
> > at multi-user scalability).
> >
> > Each of these has its own trickiness, and is harder than it
> > seems at first. :) I really have to start blogging; each of
> > these is like a separate article...
> >
> > So, yes, optimizing the lifecycle is a good start, but it's not
> > a complete solution.
> >
> > -- Adam
> >
> >
> >
> > On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > Sounds promising to me!
> > >
> > > Even though from the perfomance tests that have been posted to the
> > > mailing list a while ago, it doesn't look like going through the
> > > lifecycle is the big problem - but rather restoring/saving the state
> > > if you use client-side state saving.
> > >
> > > Adam, can you confirm that from your experience with ADF Faces?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > Thanks. That confirms what I suspected (as far as being able to have
> > > > a custom lifecycle using an init param.)
> > > >
> > > > So the suggestion would be in MyFaces to create a new custom
> lifecycle
> > > > that included the default lifecycle and other optional steps. With
> > > > the right URL or request parameter you would use the nonstandard
> > > > phases (or jump around in a non-standard way). Otherwise you would
> > > > follow the standard steps only. By default (without the special
> > > > servlet context init parameter) you would get the default lifecycle.
> > > > Would this work?
> > > >
> > > > sean
> > > >
> > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > You can configure FacesServlet to have a custom lifecycle using
> > > > > a servlet context init parameter. But you can't, say, have two
> > > > > FacesServlets each running a different lifecycle - one standard,
> > > > > one trimmed for AJAX-ing. That's what JSF 1.2 adds, because
> > > > > you can configure the lifecycle ID as a servlet config
> > > > > parameter, not just a context init parameter.
> > > > >
> > > > > -- Adam
> > > > >
> > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > I think Craig was referring to the *current* ability to
> configure a
> > > > > > custom lifecycle. From the javadocs it looks like this is
> supported.
> > > > > > Can you clarify this some?
> > > > > >
> > > > > > sean
> > > > > >
> > > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > >
> > > > > > > > For the type (a) components (where you need the component
> tree and
> > > > > > > > model), Craig offered an interesting solution. He was toying
> with the
> > > > > > > > idea of a custom lifecylce. I hadn't even realized this was
> possible
> > > > > > > > but it sounds interesting.
> > > > > > > >
> > > > > > > > I posted something on struts-dev asking him for more
> details. Not
> > > > > > > > sure if it belongs in MyFaces or Shale but it could be
> worthwhile.
> > > > > > > > Perhaps we could modify FacesServlet so that the default
> lifecycle
> > > > > > > > still applies but that you can also configure it with a
> specialized
> > > > > > > > lifecycle.
> > > > > > >
> > > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > > of the FacesServlet with different lifecycles. Jacob's idea,
> > > > > > > IIRC. (Craig hasn't been especially involved in the JSF
> > > > > > > EG for quite awhile now.)
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>

Re: Ajax lifecircle integration

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

Ok, so this would be a reason that client side state saving takes so
much longer for our load tester - GC running and running.

Right - cause it doesn't work with server side state saving either as
soon as restoreState/saveState is enabled server-side on every
request.

Then it might also have been a JDK version or OS problem, though.

Does Oracle have any concrete data on this you are allowed to share?

Maybe not into the detail, but some overview would be great ;)

regards,

Martin

On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> You probably do need to restore all of the ancestors of a component,
> since things like NamingContainers had better be present.
>
> Also, not restoring the entire tree introduces extra problems -
> especially if you want to respond to an AJAX request on one
> component by refreshing others (a common
> scenario over in ADF Faces).
>
> Martin, memory allocation can be a significant problem, not
> in terms of not having enough physical memory (that is,
> not in terms of seeing OutOfMemoryErrors) but in terms of
> pounding brutally on GC especially if you blow out the Eden
> heap.  This'd show up as CPU, but could be a consequence
> of excessive short-term memory allocation.
>
> -- Adam
>
>
> On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Yes - this is what would be the best thing to do.
> >
> > Jacob is calling this something like context-sensitive processing or so.
> >
> > regards,
> >
> > Martin
> >
> > On 11/16/05, Sean Schofield <se...@gmail.com> wrote:
> > > One idea I had was that it would be nice if you could jump right to a
> > > specific component without restoring the whole tree.  In other words
> > > you have async post for component with id of "foo" and you can grab
> > > that directly out of a session map and perform the full lifecylce (but
> > > just on that component.)
> > >
> > > If the component had children you would process them as well.  Just
> > > some random thoughts.  I'd be interested in hearing other ideas.
> > > (I'll do some research on the blogs and forums and see what others
> > > have suggested.)
> > >
> > > sean
> > >
> > > On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> > > > Martin,
> > > >
> > > > If you look at any postback, the areas that chew up time are:
> > > >
> > > > 1. Recreating the component tree
> > > > 2. Going through the full lifecycle
> > > > 3. Saving the component tree
> > > > 4. Rendering the response
> > > >
> > > > If you want a hyper-efficient async, granular JSF response, you
> > > > have to tackle each of these, both in terms of raw CPU and
> > > > memory allocation (the latter more important when you look
> > > > at multi-user scalability).
> > > >
> > > > Each of these has its own trickiness, and is harder than it
> > > > seems at first. :)  I really have to start blogging;  each of
> > > > these is like a separate article...
> > > >
> > > > So, yes, optimizing the lifecycle is a good start, but it's not
> > > > a complete solution.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > >
> > > > On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > > Sounds promising to me!
> > > > >
> > > > > Even though from the perfomance tests that have been posted to the
> > > > > mailing list a while ago, it doesn't look like going through the
> > > > > lifecycle is the big problem - but rather restoring/saving the state
> > > > > if you use client-side state saving.
> > > > >
> > > > > Adam, can you confirm that from your experience with ADF Faces?
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > Thanks.  That confirms what I suspected (as far as being able to have
> > > > > > a custom lifecycle using an init param.)
> > > > > >
> > > > > > So the suggestion would be in MyFaces to create a new custom lifecycle
> > > > > > that included the default lifecycle and other optional steps.  With
> > > > > > the right URL or request parameter  you would use the nonstandard
> > > > > > phases (or jump around in a non-standard way).  Otherwise you would
> > > > > > follow the standard steps only.  By default (without the special
> > > > > > servlet context init parameter) you would get the default lifecycle.
> > > > > > Would this work?
> > > > > >
> > > > > > sean
> > > > > >
> > > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > You can configure FacesServlet to have a custom lifecycle using
> > > > > > > a servlet context init parameter.  But you can't, say, have two
> > > > > > > FacesServlets each running a different lifecycle - one standard,
> > > > > > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > > > > > you can configure the lifecycle ID as a servlet config
> > > > > > > parameter, not just a context init parameter.
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > > I think Craig was referring to the *current* ability to configure a
> > > > > > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > > > > > Can you clarify this some?
> > > > > > > >
> > > > > > > > sean
> > > > > > > >
> > > > > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > For the type (a) components (where you need the component tree and
> > > > > > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > > > > > but it sounds interesting.
> > > > > > > > > >
> > > > > > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > > > > > still applies but that you can also configure it with a specialized
> > > > > > > > > > lifecycle.
> > > > > > > > >
> > > > > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > > > > > EG for quite awhile now.)
> > > > > > > > >
> > > > > > > > > -- Adam
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > >
> > > > > Your JSF powerhouse -
> > > > > JSF Consulting, Development and
> > > > > Courses in English and German
> > > > >
> > > > > Professional Support for Apache MyFaces
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

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

> > We can't use findComponent - that doesn't work in dataTable correctly.
> > That's (or was in 1.1) a spec problem, by the way...
>
> There was the 1.1 awfulness where getClientId() on UIData changed
> depending on the row, which got fixed in 1.2 - is that what you're thinking
> of?  You still can't call findComponent() with a clientId that includes a
> row number and expect it to find anything.
>
> -- Adam
>
>

Yes, ok, so we'll need to render through the whole dataTable and
stop/start the actual output on certain rows. Sounds promising with
regards to performance ;)

Have you guys solved all of this in ADF faces already?

regards,

Martin

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

On 11/17/05, Martin Marinschek <ma...@gmail.com> wrote:
> That might work.
>
> You'll also need to take into account that components might be
> referencing other components - as with the label and the inputText,
> the dataScroller and the dataTable.

It's basically kinda lame restricting AJAX updates to just AJAX-enabled
components, because then you end up needing to make this knowledge
pervasive across all renderers, which is awful.  Optimizing some
renderers to be especially slick and cool at dealing with AJAX,
great.

> Eventually, this might be the same problem as with what Adam has described.
>
> An Ajax enabled component updates on an action another component - and
> is bound to this other component via a for attribute. Multiple
> components could be handled with grouping, facets allow only one
> component as well ;). Those two components would be recreated.
>
> I don't think this is undoable, but next problem: imagine Ajax enabled
> components in a dataTable, dataList, whatever.

Yep!  Gets tricky.  The trick - once you get to things like this - is
running a ResponseWriter that drops most generated content,
and turns itself on when you hit the right component.

> And we all know for a feature/component to really work, it needs to
> work in a dataTable, right? How would we go through the lifecycle -
> would we step into the necessary iterations in dataTable to go through
> the whole dataModel? To come to the actual component representation we
> want to use later on? What about saving states here? Are we only
> saving states of those component representations we need?
>
> We can't use findComponent - that doesn't work in dataTable correctly.
> That's (or was in 1.1) a spec problem, by the way...

There was the 1.1 awfulness where getClientId() on UIData changed
depending on the row, which got fixed in 1.2 - is that what you're thinking
of?  You still can't call findComponent() with a clientId that includes a
row number and expect it to find anything.

-- Adam

Re: Ajax lifecircle integration

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

That might work.

You'll also need to take into account that components might be
referencing other components - as with the label and the inputText,
the dataScroller and the dataTable.

Eventually, this might be the same problem as with what Adam has described.

An Ajax enabled component updates on an action another component - and
is bound to this other component via a for attribute. Multiple
components could be handled with grouping, facets allow only one
component as well ;). Those two components would be recreated.

I don't think this is undoable, but next problem: imagine Ajax enabled
components in a dataTable, dataList, whatever.

And we all know for a feature/component to really work, it needs to
work in a dataTable, right? How would we go through the lifecycle -
would we step into the necessary iterations in dataTable to go through
the whole dataModel? To come to the actual component representation we
want to use later on? What about saving states here? Are we only
saving states of those component representations we need?

We can't use findComponent - that doesn't work in dataTable correctly.
That's (or was in 1.1) a spec problem, by the way...

regards,

Martin


On 11/17/05, Sean Schofield <se...@gmail.com> wrote:
> > how would that work? updating the beans doesn't help as we are not
> > rendering this part out.
>
> True.  This is a pretty complicated scenario to handle by ajax (no
> matter what solution you want.)  What about the idea of restoring the
> ajax components only?
>
> > regards,
> >
> > Martin
> >
>
> sean
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

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

> how would that work? updating the beans doesn't help as we are not
> rendering this part out.

True.  This is a pretty complicated scenario to handle by ajax (no
matter what solution you want.)  What about the idea of restoring the
ajax components only?

> regards,
>
> Martin
>

sean

Re: Ajax lifecircle integration

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

> > Also, not restoring the entire tree introduces extra problems -
> > especially if you want to respond to an AJAX request on one
> > component by refreshing others (a common
> > scenario over in ADF Faces).
>
> Hmm.  I hadn't thought of that.  I guess this might be a serious
> limitation.  Do you think we could get away with updating only one
> component and handling the rest by updating the backing beans of the
> others?
>

how would that work? updating the beans doesn't help as we are not
rendering this part out.

regards,

Martin

Re: Ajax lifecircle integration

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

> You probably do need to restore all of the ancestors of a component,
> since things like NamingContainers had better be present.

I'm not so sure about the naming container aspect.  If the components
all used forceId you could store the component by client id.

On the other hand for rendering purposes (take the ajax tree example)
you probably would need the children so you can render the images,
checkboxes, etc. that are inside of a tree node.

> Also, not restoring the entire tree introduces extra problems -
> especially if you want to respond to an AJAX request on one
> component by refreshing others (a common
> scenario over in ADF Faces).

Hmm.  I hadn't thought of that.  I guess this might be a serious
limitation.  Do you think we could get away with updating only one
component and handling the rest by updating the backing beans of the
others?

Another idea might be to only store the components for a particular
view that are ajax enabled (and their children.)  You could restore
all of them automatically during the special lifcylce (Restore Partial
View.)  Just thinking of the top of my head here ...

[snip]

> -- Adam

sean

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

You probably do need to restore all of the ancestors of a component,
since things like NamingContainers had better be present.

Also, not restoring the entire tree introduces extra problems -
especially if you want to respond to an AJAX request on one
component by refreshing others (a common
scenario over in ADF Faces).

Martin, memory allocation can be a significant problem, not
in terms of not having enough physical memory (that is,
not in terms of seeing OutOfMemoryErrors) but in terms of
pounding brutally on GC especially if you blow out the Eden
heap.  This'd show up as CPU, but could be a consequence
of excessive short-term memory allocation.

-- Adam


On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> Yes - this is what would be the best thing to do.
>
> Jacob is calling this something like context-sensitive processing or so.
>
> regards,
>
> Martin
>
> On 11/16/05, Sean Schofield <se...@gmail.com> wrote:
> > One idea I had was that it would be nice if you could jump right to a
> > specific component without restoring the whole tree.  In other words
> > you have async post for component with id of "foo" and you can grab
> > that directly out of a session map and perform the full lifecylce (but
> > just on that component.)
> >
> > If the component had children you would process them as well.  Just
> > some random thoughts.  I'd be interested in hearing other ideas.
> > (I'll do some research on the blogs and forums and see what others
> > have suggested.)
> >
> > sean
> >
> > On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> > > Martin,
> > >
> > > If you look at any postback, the areas that chew up time are:
> > >
> > > 1. Recreating the component tree
> > > 2. Going through the full lifecycle
> > > 3. Saving the component tree
> > > 4. Rendering the response
> > >
> > > If you want a hyper-efficient async, granular JSF response, you
> > > have to tackle each of these, both in terms of raw CPU and
> > > memory allocation (the latter more important when you look
> > > at multi-user scalability).
> > >
> > > Each of these has its own trickiness, and is harder than it
> > > seems at first. :)  I really have to start blogging;  each of
> > > these is like a separate article...
> > >
> > > So, yes, optimizing the lifecycle is a good start, but it's not
> > > a complete solution.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > > Sounds promising to me!
> > > >
> > > > Even though from the perfomance tests that have been posted to the
> > > > mailing list a while ago, it doesn't look like going through the
> > > > lifecycle is the big problem - but rather restoring/saving the state
> > > > if you use client-side state saving.
> > > >
> > > > Adam, can you confirm that from your experience with ADF Faces?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > Thanks.  That confirms what I suspected (as far as being able to have
> > > > > a custom lifecycle using an init param.)
> > > > >
> > > > > So the suggestion would be in MyFaces to create a new custom lifecycle
> > > > > that included the default lifecycle and other optional steps.  With
> > > > > the right URL or request parameter  you would use the nonstandard
> > > > > phases (or jump around in a non-standard way).  Otherwise you would
> > > > > follow the standard steps only.  By default (without the special
> > > > > servlet context init parameter) you would get the default lifecycle.
> > > > > Would this work?
> > > > >
> > > > > sean
> > > > >
> > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > You can configure FacesServlet to have a custom lifecycle using
> > > > > > a servlet context init parameter.  But you can't, say, have two
> > > > > > FacesServlets each running a different lifecycle - one standard,
> > > > > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > > > > you can configure the lifecycle ID as a servlet config
> > > > > > parameter, not just a context init parameter.
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > I think Craig was referring to the *current* ability to configure a
> > > > > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > > > > Can you clarify this some?
> > > > > > >
> > > > > > > sean
> > > > > > >
> > > > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > For the type (a) components (where you need the component tree and
> > > > > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > > > > but it sounds interesting.
> > > > > > > > >
> > > > > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > > > > still applies but that you can also configure it with a specialized
> > > > > > > > > lifecycle.
> > > > > > > >
> > > > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > > > > EG for quite awhile now.)
> > > > > > > >
> > > > > > > > -- Adam
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Ajax lifecircle integration

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

Yes - this is what would be the best thing to do.

Jacob is calling this something like context-sensitive processing or so.

regards,

Martin

On 11/16/05, Sean Schofield <se...@gmail.com> wrote:
> One idea I had was that it would be nice if you could jump right to a
> specific component without restoring the whole tree.  In other words
> you have async post for component with id of "foo" and you can grab
> that directly out of a session map and perform the full lifecylce (but
> just on that component.)
>
> If the component had children you would process them as well.  Just
> some random thoughts.  I'd be interested in hearing other ideas.
> (I'll do some research on the blogs and forums and see what others
> have suggested.)
>
> sean
>
> On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> > Martin,
> >
> > If you look at any postback, the areas that chew up time are:
> >
> > 1. Recreating the component tree
> > 2. Going through the full lifecycle
> > 3. Saving the component tree
> > 4. Rendering the response
> >
> > If you want a hyper-efficient async, granular JSF response, you
> > have to tackle each of these, both in terms of raw CPU and
> > memory allocation (the latter more important when you look
> > at multi-user scalability).
> >
> > Each of these has its own trickiness, and is harder than it
> > seems at first. :)  I really have to start blogging;  each of
> > these is like a separate article...
> >
> > So, yes, optimizing the lifecycle is a good start, but it's not
> > a complete solution.
> >
> > -- Adam
> >
> >
> >
> > On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > > Sounds promising to me!
> > >
> > > Even though from the perfomance tests that have been posted to the
> > > mailing list a while ago, it doesn't look like going through the
> > > lifecycle is the big problem - but rather restoring/saving the state
> > > if you use client-side state saving.
> > >
> > > Adam, can you confirm that from your experience with ADF Faces?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > Thanks.  That confirms what I suspected (as far as being able to have
> > > > a custom lifecycle using an init param.)
> > > >
> > > > So the suggestion would be in MyFaces to create a new custom lifecycle
> > > > that included the default lifecycle and other optional steps.  With
> > > > the right URL or request parameter  you would use the nonstandard
> > > > phases (or jump around in a non-standard way).  Otherwise you would
> > > > follow the standard steps only.  By default (without the special
> > > > servlet context init parameter) you would get the default lifecycle.
> > > > Would this work?
> > > >
> > > > sean
> > > >
> > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > You can configure FacesServlet to have a custom lifecycle using
> > > > > a servlet context init parameter.  But you can't, say, have two
> > > > > FacesServlets each running a different lifecycle - one standard,
> > > > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > > > you can configure the lifecycle ID as a servlet config
> > > > > parameter, not just a context init parameter.
> > > > >
> > > > > -- Adam
> > > > >
> > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > I think Craig was referring to the *current* ability to configure a
> > > > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > > > Can you clarify this some?
> > > > > >
> > > > > > sean
> > > > > >
> > > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > > >
> > > > > > > > For the type (a) components (where you need the component tree and
> > > > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > > > but it sounds interesting.
> > > > > > > >
> > > > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > > > still applies but that you can also configure it with a specialized
> > > > > > > > lifecycle.
> > > > > > >
> > > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > > > EG for quite awhile now.)
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

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

One idea I had was that it would be nice if you could jump right to a
specific component without restoring the whole tree.  In other words
you have async post for component with id of "foo" and you can grab
that directly out of a session map and perform the full lifecylce (but
just on that component.)

If the component had children you would process them as well.  Just
some random thoughts.  I'd be interested in hearing other ideas. 
(I'll do some research on the blogs and forums and see what others
have suggested.)

sean

On 11/16/05, Adam Winer <aw...@gmail.com> wrote:
> Martin,
>
> If you look at any postback, the areas that chew up time are:
>
> 1. Recreating the component tree
> 2. Going through the full lifecycle
> 3. Saving the component tree
> 4. Rendering the response
>
> If you want a hyper-efficient async, granular JSF response, you
> have to tackle each of these, both in terms of raw CPU and
> memory allocation (the latter more important when you look
> at multi-user scalability).
>
> Each of these has its own trickiness, and is harder than it
> seems at first. :)  I really have to start blogging;  each of
> these is like a separate article...
>
> So, yes, optimizing the lifecycle is a good start, but it's not
> a complete solution.
>
> -- Adam
>
>
>
> On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Sounds promising to me!
> >
> > Even though from the perfomance tests that have been posted to the
> > mailing list a while ago, it doesn't look like going through the
> > lifecycle is the big problem - but rather restoring/saving the state
> > if you use client-side state saving.
> >
> > Adam, can you confirm that from your experience with ADF Faces?
> >
> > regards,
> >
> > Martin
> >
> > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > Thanks.  That confirms what I suspected (as far as being able to have
> > > a custom lifecycle using an init param.)
> > >
> > > So the suggestion would be in MyFaces to create a new custom lifecycle
> > > that included the default lifecycle and other optional steps.  With
> > > the right URL or request parameter  you would use the nonstandard
> > > phases (or jump around in a non-standard way).  Otherwise you would
> > > follow the standard steps only.  By default (without the special
> > > servlet context init parameter) you would get the default lifecycle.
> > > Would this work?
> > >
> > > sean
> > >
> > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > You can configure FacesServlet to have a custom lifecycle using
> > > > a servlet context init parameter.  But you can't, say, have two
> > > > FacesServlets each running a different lifecycle - one standard,
> > > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > > you can configure the lifecycle ID as a servlet config
> > > > parameter, not just a context init parameter.
> > > >
> > > > -- Adam
> > > >
> > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > I think Craig was referring to the *current* ability to configure a
> > > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > > Can you clarify this some?
> > > > >
> > > > > sean
> > > > >
> > > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > >
> > > > > > > For the type (a) components (where you need the component tree and
> > > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > > but it sounds interesting.
> > > > > > >
> > > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > > still applies but that you can also configure it with a specialized
> > > > > > > lifecycle.
> > > > > >
> > > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > > EG for quite awhile now.)
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

Martin,

If you look at any postback, the areas that chew up time are:

1. Recreating the component tree
2. Going through the full lifecycle
3. Saving the component tree
4. Rendering the response

If you want a hyper-efficient async, granular JSF response, you
have to tackle each of these, both in terms of raw CPU and
memory allocation (the latter more important when you look
at multi-user scalability).

Each of these has its own trickiness, and is harder than it
seems at first. :)  I really have to start blogging;  each of
these is like a separate article...

So, yes, optimizing the lifecycle is a good start, but it's not
a complete solution.

-- Adam



On 11/16/05, Martin Marinschek <ma...@gmail.com> wrote:
> Sounds promising to me!
>
> Even though from the perfomance tests that have been posted to the
> mailing list a while ago, it doesn't look like going through the
> lifecycle is the big problem - but rather restoring/saving the state
> if you use client-side state saving.
>
> Adam, can you confirm that from your experience with ADF Faces?
>
> regards,
>
> Martin
>
> On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > Thanks.  That confirms what I suspected (as far as being able to have
> > a custom lifecycle using an init param.)
> >
> > So the suggestion would be in MyFaces to create a new custom lifecycle
> > that included the default lifecycle and other optional steps.  With
> > the right URL or request parameter  you would use the nonstandard
> > phases (or jump around in a non-standard way).  Otherwise you would
> > follow the standard steps only.  By default (without the special
> > servlet context init parameter) you would get the default lifecycle.
> > Would this work?
> >
> > sean
> >
> > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > You can configure FacesServlet to have a custom lifecycle using
> > > a servlet context init parameter.  But you can't, say, have two
> > > FacesServlets each running a different lifecycle - one standard,
> > > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > > you can configure the lifecycle ID as a servlet config
> > > parameter, not just a context init parameter.
> > >
> > > -- Adam
> > >
> > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > I think Craig was referring to the *current* ability to configure a
> > > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > > Can you clarify this some?
> > > >
> > > > sean
> > > >
> > > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > > >
> > > > > > For the type (a) components (where you need the component tree and
> > > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > > but it sounds interesting.
> > > > > >
> > > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > > still applies but that you can also configure it with a specialized
> > > > > > lifecycle.
> > > > >
> > > > > JSF 1.2 offers support for configuring multiple instances
> > > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > > EG for quite awhile now.)
> > > > >
> > > > > -- Adam
> > > > >
> > > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Ajax lifecircle integration

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

Sounds promising to me!

Even though from the perfomance tests that have been posted to the
mailing list a while ago, it doesn't look like going through the
lifecycle is the big problem - but rather restoring/saving the state
if you use client-side state saving.

Adam, can you confirm that from your experience with ADF Faces?

regards,

Martin

On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> Thanks.  That confirms what I suspected (as far as being able to have
> a custom lifecycle using an init param.)
>
> So the suggestion would be in MyFaces to create a new custom lifecycle
> that included the default lifecycle and other optional steps.  With
> the right URL or request parameter  you would use the nonstandard
> phases (or jump around in a non-standard way).  Otherwise you would
> follow the standard steps only.  By default (without the special
> servlet context init parameter) you would get the default lifecycle.
> Would this work?
>
> sean
>
> On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > You can configure FacesServlet to have a custom lifecycle using
> > a servlet context init parameter.  But you can't, say, have two
> > FacesServlets each running a different lifecycle - one standard,
> > one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> > you can configure the lifecycle ID as a servlet config
> > parameter, not just a context init parameter.
> >
> > -- Adam
> >
> > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > I think Craig was referring to the *current* ability to configure a
> > > custom lifecycle.  From the javadocs it looks like this is supported.
> > > Can you clarify this some?
> > >
> > > sean
> > >
> > > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > > >
> > > > > For the type (a) components (where you need the component tree and
> > > > > model), Craig offered an interesting solution.  He was toying with the
> > > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > > but it sounds interesting.
> > > > >
> > > > > I posted something on struts-dev asking him for more details.  Not
> > > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > > still applies but that you can also configure it with a specialized
> > > > > lifecycle.
> > > >
> > > > JSF 1.2 offers support for configuring multiple instances
> > > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > > EG for quite awhile now.)
> > > >
> > > > -- Adam
> > > >
> > >
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

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

Thanks.  That confirms what I suspected (as far as being able to have
a custom lifecycle using an init param.)

So the suggestion would be in MyFaces to create a new custom lifecycle
that included the default lifecycle and other optional steps.  With
the right URL or request parameter  you would use the nonstandard
phases (or jump around in a non-standard way).  Otherwise you would
follow the standard steps only.  By default (without the special
servlet context init parameter) you would get the default lifecycle. 
Would this work?

sean

On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> You can configure FacesServlet to have a custom lifecycle using
> a servlet context init parameter.  But you can't, say, have two
> FacesServlets each running a different lifecycle - one standard,
> one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
> you can configure the lifecycle ID as a servlet config
> parameter, not just a context init parameter.
>
> -- Adam
>
> On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > I think Craig was referring to the *current* ability to configure a
> > custom lifecycle.  From the javadocs it looks like this is supported.
> > Can you clarify this some?
> >
> > sean
> >
> > On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> > >
> > > > For the type (a) components (where you need the component tree and
> > > > model), Craig offered an interesting solution.  He was toying with the
> > > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > > but it sounds interesting.
> > > >
> > > > I posted something on struts-dev asking him for more details.  Not
> > > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > > still applies but that you can also configure it with a specialized
> > > > lifecycle.
> > >
> > > JSF 1.2 offers support for configuring multiple instances
> > > of the FacesServlet with different lifecycles.  Jacob's idea,
> > > IIRC.  (Craig hasn't been especially involved in the JSF
> > > EG for quite awhile now.)
> > >
> > > -- Adam
> > >
> >
>

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

You can configure FacesServlet to have a custom lifecycle using
a servlet context init parameter.  But you can't, say, have two
FacesServlets each running a different lifecycle - one standard,
one trimmed for AJAX-ing.  That's what JSF 1.2 adds, because
you can configure the lifecycle ID as a servlet config
parameter, not just a context init parameter.

-- Adam

On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> I think Craig was referring to the *current* ability to configure a
> custom lifecycle.  From the javadocs it looks like this is supported.
> Can you clarify this some?
>
> sean
>
> On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> >
> > > For the type (a) components (where you need the component tree and
> > > model), Craig offered an interesting solution.  He was toying with the
> > > idea of a custom lifecylce.  I hadn't even realized this was possible
> > > but it sounds interesting.
> > >
> > > I posted something on struts-dev asking him for more details.  Not
> > > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > > Perhaps we could modify FacesServlet so that the default lifecycle
> > > still applies but that you can also configure it with a specialized
> > > lifecycle.
> >
> > JSF 1.2 offers support for configuring multiple instances
> > of the FacesServlet with different lifecycles.  Jacob's idea,
> > IIRC.  (Craig hasn't been especially involved in the JSF
> > EG for quite awhile now.)
> >
> > -- Adam
> >
>

Re: Ajax lifecircle integration

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

I think Craig was referring to the *current* ability to configure a
custom lifecycle.  From the javadocs it looks like this is supported. 
Can you clarify this some?

sean

On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
>
> > For the type (a) components (where you need the component tree and
> > model), Craig offered an interesting solution.  He was toying with the
> > idea of a custom lifecylce.  I hadn't even realized this was possible
> > but it sounds interesting.
> >
> > I posted something on struts-dev asking him for more details.  Not
> > sure if it belongs in MyFaces or Shale but it could be worthwhile.
> > Perhaps we could modify FacesServlet so that the default lifecycle
> > still applies but that you can also configure it with a specialized
> > lifecycle.
>
> JSF 1.2 offers support for configuring multiple instances
> of the FacesServlet with different lifecycles.  Jacob's idea,
> IIRC.  (Craig hasn't been especially involved in the JSF
> EG for quite awhile now.)
>
> -- Adam
>

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

On 11/15/05, Sean Schofield <se...@gmail.com> wrote:

> For the type (a) components (where you need the component tree and
> model), Craig offered an interesting solution.  He was toying with the
> idea of a custom lifecylce.  I hadn't even realized this was possible
> but it sounds interesting.
>
> I posted something on struts-dev asking him for more details.  Not
> sure if it belongs in MyFaces or Shale but it could be worthwhile.
> Perhaps we could modify FacesServlet so that the default lifecycle
> still applies but that you can also configure it with a specialized
> lifecycle.

JSF 1.2 offers support for configuring multiple instances
of the FacesServlet with different lifecycles.  Jacob's idea,
IIRC.  (Craig hasn't been especially involved in the JSF
EG for quite awhile now.)

-- Adam

Re: Ajax lifecircle integration

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

For the type (a) components (where you need the component tree and
model), Craig offered an interesting solution.  He was toying with the
idea of a custom lifecylce.  I hadn't even realized this was possible
but it sounds interesting.

I posted something on struts-dev asking him for more details.  Not
sure if it belongs in MyFaces or Shale but it could be worthwhile. 
Perhaps we could modify FacesServlet so that the default lifecycle
still applies but that you can also configure it with a specialized
lifecycle.

sean

On 11/15/05, Travis Reeder <tr...@gmail.com> wrote:
> I am with Adam on this.  The JSF spec didn't consider AJAX, I'm sure because
> it was designed before Google started shaking things up, but now that it's
> hear and it appears to be hear to stay, the spec has to keep up.
>
> Using the PhaseListener like we are doing now, we decode before Apply
> Request Values phase.  Can we not just do the lifecycle on the affected
> components and bypass the rest of the lifecycle for the everything else?
>
> Travis
>
>
>
> On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
> > On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > > On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> > > > On 11/14/05, Sean Schofield < sean.schofield@gmail.com> wrote:
> > > > > > Remember - the JSF framework was an outcome of seeing  the
> necessity
> > > > > > of componentization, state saving, etc. Why should that be any
> > > > > > different for AJAX components?
> > > > >
> > > > > Because it may be overkill in some instances.  I don't think an Ajax
> > > > > component that goes through the entire JSF lifecycle with every
> > > > > keystroke will scale very well.
> > > >
> > > > Certainly not - but that's just about what we can do today.
> > > > If this could scale, you've got more options.
> > >
> > > But for right now we need something other then complete JSF lifecycle
> > > for certain ajax components.  So what do we do about that in the here
> > > and now?
> >
> > Fair enough - with JSF 1.1 (and JSF 1.2, for that matter), AJAX
> > postback back through the component tree is somewhere between
> > slower than ideal and molasses-slow.  But it's my opinion that
> > bypassing JSF is a workaround for limitations in JSF, not a
> > desirable path in and of itself.  And so its the job of the EG
> > and the JSF community (like MyFaces) to figure out how we
> > can fix JSF to make it better for processing AJAX requests.
> >
> > -- Adam
> >
>
>

Re: Ajax lifecircle integration

[Travis Reeder <tr...@gmail.com>]

I am with Adam on this. The JSF spec didn't consider AJAX, I'm sure because
it was designed before Google started shaking things up, but now that it's
hear and it appears to be hear to stay, the spec has to keep up.

Using the PhaseListener like we are doing now, we decode before Apply
Request Values phase. Can we not just do the lifecycle on the affected
components and bypass the rest of the lifecycle for the everything else?

Travis


On 11/15/05, Adam Winer <aw...@gmail.com> wrote:
>
> On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> > > On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > > > > Remember - the JSF framework was an outcome of seeing the
> necessity
> > > > > of componentization, state saving, etc. Why should that be any
> > > > > different for AJAX components?
> > > >
> > > > Because it may be overkill in some instances. I don't think an Ajax
> > > > component that goes through the entire JSF lifecycle with every
> > > > keystroke will scale very well.
> > >
> > > Certainly not - but that's just about what we can do today.
> > > If this could scale, you've got more options.
> >
> > But for right now we need something other then complete JSF lifecycle
> > for certain ajax components. So what do we do about that in the here
> > and now?
>
> Fair enough - with JSF 1.1 (and JSF 1.2, for that matter), AJAX
> postback back through the component tree is somewhere between
> slower than ideal and molasses-slow. But it's my opinion that
> bypassing JSF is a workaround for limitations in JSF, not a
> desirable path in and of itself. And so its the job of the EG
> and the JSF community (like MyFaces) to figure out how we
> can fix JSF to make it better for processing AJAX requests.
>
> -- Adam
>

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> > On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > > > Remember - the JSF framework was an outcome of seeing  the necessity
> > > > of componentization, state saving, etc. Why should that be any
> > > > different for AJAX components?
> > >
> > > Because it may be overkill in some instances.  I don't think an Ajax
> > > component that goes through the entire JSF lifecycle with every
> > > keystroke will scale very well.
> >
> > Certainly not - but that's just about what we can do today.
> > If this could scale, you've got more options.
>
> But for right now we need something other then complete JSF lifecycle
> for certain ajax components.  So what do we do about that in the here
> and now?

Fair enough - with JSF 1.1 (and JSF 1.2, for that matter), AJAX
postback back through the component tree is somewhere between
slower than ideal and molasses-slow.  But it's my opinion that
bypassing JSF is a workaround for limitations in JSF, not a
desirable path in and of itself.  And so its the job of the EG
and the JSF community (like MyFaces) to figure out how we
can fix JSF to make it better for processing AJAX requests.

-- Adam

Re: Ajax lifecircle integration

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

Yes - I needed to make a distinction between the inputSuggest that
originally was there and the AJAXified version.

Of course, it would be better to don't reflect that in the name.

As for the performance: there is work in progress to change the
available HTTP-Servers to better cope with frequent request which
deliver small data - that might help in the future.

regards,

Martin

On 11/15/05, Sean Schofield <se...@gmail.com> wrote:
> On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> > On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > > [snip]
> > >
> > > > You cannot expect that you want to show the same autocomplete to every
> > > > user that comes in - this really is a very seldom case. You want to
> > > > depicture I18N, session information and user permissions just like
> > > > with a JSF component.
> > >
> > > I have been reading up on Craig's remoting solution for the (b) case.
> > > The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
> > > access it in your code using FacesContext.getCurrentInstance().
> > >
> > > This means that you *can* have some of the JSF goodness without the
> > > overhead of the lifecycle.  You can use method and value binding
> > > expressions as well as locale stuff.
> >
> > ... which is nice, but not as nice as actually having the actual
> > component instance.
>
> In the case of inputSuggestAjax we don't need the component instance.
> We just want a refined list of possible choices based on the user's
> latest keystroke.  I think the Tomahawk components that use Ajax will
> want to allow this option.
>
> > > > Remember - the JSF framework was an outcome of seeing  the necessity
> > > > of componentization, state saving, etc. Why should that be any
> > > > different for AJAX components?
> > >
> > > Because it may be overkill in some instances.  I don't think an Ajax
> > > component that goes through the entire JSF lifecycle with every
> > > keystroke will scale very well.
> >
> > Certainly not - but that's just about what we can do today.
> > If this could scale, you've got more options.
>
> But for right now we need something other then complete JSF lifecycle
> for certain ajax components.  So what do we do about that in the here
> and now?
>
> My suggestion is that we don't require a JSF postback every keystroke.
>  I think we can modify inputSuggestAjax and other similar components
> that fall under the (b) case and make them more flexible.  Allow the
> user to use Shale's remote command if they want to.  Don't lock them
> into the full JSF lifecycle.
>
> > >  In inputSuggestAjax, the list of
> > > possible choices is meaningless.  It's not necessary to store in the
> > > state.  Only their final answer is important.
> >
> > But OTOH, the component - and what model its bound to -
> > is of course correlated to which list of possible choices make
> > sense.
> >
> > It'd be excellent to have:
> >
> >   <t:inputSuggestAjax value="#{theValue}"
> >             possibleValues="#{aListOfPossibleValues}"/>
> >
> > ... and this is worlds simpler than setting up an XMLHttp
> > endpoint.  The problem is that today this simply isn't scalable;
> > the issue for JSF is making it so.
> >
> > > I agree that more complicated components (like an AjaxTree) would need
> > > to worry about this.  In fact, that is a big PITA right now with tree2
> > > and the client side script.  You need to post back (via a cookie) your
> > > client side state changes so you can sync them up.
> >
> > A good candidate for mixing in some component-tree-based AJAX
> > requests, though you'd certainly want to buffer them up
> > instead of sending requests on very expand/collapse, unless
> > you needed extra data sent across (another example of something
> > that's far easier to achieve with the component tree than without).
>
> I thought about the buffering issue.  While it speeds things up, it
> also certainly complicates things.  For large trees, the client-side
> toggle is too slow (especially on IE browsers.)  So some type of Ajax
> solution would be nice.  I'd definitely consider working on an Ajax
> tree with anyone who was interested.  I just don't want to get stuck
> doing all of the work myself.
>
> > BTW, other than following existing hype conventions, what's
> > the reason for putting "Ajax" in the name of these tags (or,
> > even worse, Java method names)?  The abstraction
> > (asynchronous granular requests) is what matters, not the
> > latest rubric or the particular transport protocol.
>
> Well I had already contributed an inputSuggest to the sandbox that did
> *not* use Ajax.  So the authors of this one decided to distinguish it.
>  I've lost interest in the original inputSuggest, however, because its
> just not very good with large lists (too slow.)  It has some good
> javascript and DHTML that we can make use of in the Ajax version but
> perhaps its time to abandon it.
>
> I'm ok with dropping "ajax" from the names but you'll have to convince
> a bunch of others.
>
> > Cheers,
> > Adam Winer
>
> sean
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

[Bruno Aranda <br...@gmail.com>]

2005/11/15, Sean Schofield <se...@gmail.com>:
> On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> > On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > > [snip]
> > >
> > > > You cannot expect that you want to show the same autocomplete to every
> > > > user that comes in - this really is a very seldom case. You want to
> > > > depicture I18N, session information and user permissions just like
> > > > with a JSF component.
> > >
> > > I have been reading up on Craig's remoting solution for the (b) case.
> > > The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
> > > access it in your code using FacesContext.getCurrentInstance().
> > >
> > > This means that you *can* have some of the JSF goodness without the
> > > overhead of the lifecycle.  You can use method and value binding
> > > expressions as well as locale stuff.
> >
> > ... which is nice, but not as nice as actually having the actual
> > component instance.
>
> In the case of inputSuggestAjax we don't need the component instance.
> We just want a refined list of possible choices based on the user's
> latest keystroke.  I think the Tomahawk components that use Ajax will
> want to allow this option.
>
> > > > Remember - the JSF framework was an outcome of seeing  the necessity
> > > > of componentization, state saving, etc. Why should that be any
> > > > different for AJAX components?
> > >
> > > Because it may be overkill in some instances.  I don't think an Ajax
> > > component that goes through the entire JSF lifecycle with every
> > > keystroke will scale very well.
> >
> > Certainly not - but that's just about what we can do today.
> > If this could scale, you've got more options.
>
> But for right now we need something other then complete JSF lifecycle
> for certain ajax components.  So what do we do about that in the here
> and now?
>
> My suggestion is that we don't require a JSF postback every keystroke.
>  I think we can modify inputSuggestAjax and other similar components
> that fall under the (b) case and make them more flexible.  Allow the
> user to use Shale's remote command if they want to.  Don't lock them
> into the full JSF lifecycle.
>
> > >  In inputSuggestAjax, the list of
> > > possible choices is meaningless.  It's not necessary to store in the
> > > state.  Only their final answer is important.
> >
> > But OTOH, the component - and what model its bound to -
> > is of course correlated to which list of possible choices make
> > sense.
> >
> > It'd be excellent to have:
> >
> >   <t:inputSuggestAjax value="#{theValue}"
> >             possibleValues="#{aListOfPossibleValues}"/>
> >
> > ... and this is worlds simpler than setting up an XMLHttp
> > endpoint.  The problem is that today this simply isn't scalable;
> > the issue for JSF is making it so.
> >
> > > I agree that more complicated components (like an AjaxTree) would need
> > > to worry about this.  In fact, that is a big PITA right now with tree2
> > > and the client side script.  You need to post back (via a cookie) your
> > > client side state changes so you can sync them up.
> >
> > A good candidate for mixing in some component-tree-based AJAX
> > requests, though you'd certainly want to buffer them up
> > instead of sending requests on very expand/collapse, unless
> > you needed extra data sent across (another example of something
> > that's far easier to achieve with the component tree than without).
>
> I thought about the buffering issue.  While it speeds things up, it
> also certainly complicates things.  For large trees, the client-side
> toggle is too slow (especially on IE browsers.)  So some type of Ajax
> solution would be nice.  I'd definitely consider working on an Ajax
> tree with anyone who was interested.  I just don't want to get stuck
> doing all of the work myself.

For the ajax tree, some efforts have been made by Veerendra Shivhare
(http://www.mail-archive.com/users%40myfaces.apache.org/msg11965.html).
We still don't know if he wants to contribute code though.

>
> > BTW, other than following existing hype conventions, what's
> > the reason for putting "Ajax" in the name of these tags (or,
> > even worse, Java method names)?  The abstraction
> > (asynchronous granular requests) is what matters, not the
> > latest rubric or the particular transport protocol.
>
> Well I had already contributed an inputSuggest to the sandbox that did
> *not* use Ajax.  So the authors of this one decided to distinguish it.
>  I've lost interest in the original inputSuggest, however, because its
> just not very good with large lists (too slow.)  It has some good
> javascript and DHTML that we can make use of in the Ajax version but
> perhaps its time to abandon it.
>
> I'm ok with dropping "ajax" from the names but you'll have to convince
> a bunch of others.

+1 Maybe we could use a prefix such as 'asyn'.

>
> > Cheers,
> > Adam Winer
>
> sean
>

Regards,

Bruno

Re: Ajax lifecircle integration

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

On 11/14/05, Adam Winer <aw...@gmail.com> wrote:
> On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > [snip]
> >
> > > You cannot expect that you want to show the same autocomplete to every
> > > user that comes in - this really is a very seldom case. You want to
> > > depicture I18N, session information and user permissions just like
> > > with a JSF component.
> >
> > I have been reading up on Craig's remoting solution for the (b) case.
> > The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
> > access it in your code using FacesContext.getCurrentInstance().
> >
> > This means that you *can* have some of the JSF goodness without the
> > overhead of the lifecycle.  You can use method and value binding
> > expressions as well as locale stuff.
>
> ... which is nice, but not as nice as actually having the actual
> component instance.

In the case of inputSuggestAjax we don't need the component instance. 
We just want a refined list of possible choices based on the user's
latest keystroke.  I think the Tomahawk components that use Ajax will
want to allow this option.

> > > Remember - the JSF framework was an outcome of seeing  the necessity
> > > of componentization, state saving, etc. Why should that be any
> > > different for AJAX components?
> >
> > Because it may be overkill in some instances.  I don't think an Ajax
> > component that goes through the entire JSF lifecycle with every
> > keystroke will scale very well.
>
> Certainly not - but that's just about what we can do today.
> If this could scale, you've got more options.

But for right now we need something other then complete JSF lifecycle
for certain ajax components.  So what do we do about that in the here
and now?

My suggestion is that we don't require a JSF postback every keystroke.
 I think we can modify inputSuggestAjax and other similar components
that fall under the (b) case and make them more flexible.  Allow the
user to use Shale's remote command if they want to.  Don't lock them
into the full JSF lifecycle.

> >  In inputSuggestAjax, the list of
> > possible choices is meaningless.  It's not necessary to store in the
> > state.  Only their final answer is important.
>
> But OTOH, the component - and what model its bound to -
> is of course correlated to which list of possible choices make
> sense.
>
> It'd be excellent to have:
>
>   <t:inputSuggestAjax value="#{theValue}"
>             possibleValues="#{aListOfPossibleValues}"/>
>
> ... and this is worlds simpler than setting up an XMLHttp
> endpoint.  The problem is that today this simply isn't scalable;
> the issue for JSF is making it so.
>
> > I agree that more complicated components (like an AjaxTree) would need
> > to worry about this.  In fact, that is a big PITA right now with tree2
> > and the client side script.  You need to post back (via a cookie) your
> > client side state changes so you can sync them up.
>
> A good candidate for mixing in some component-tree-based AJAX
> requests, though you'd certainly want to buffer them up
> instead of sending requests on very expand/collapse, unless
> you needed extra data sent across (another example of something
> that's far easier to achieve with the component tree than without).

I thought about the buffering issue.  While it speeds things up, it
also certainly complicates things.  For large trees, the client-side
toggle is too slow (especially on IE browsers.)  So some type of Ajax
solution would be nice.  I'd definitely consider working on an Ajax
tree with anyone who was interested.  I just don't want to get stuck
doing all of the work myself.

> BTW, other than following existing hype conventions, what's
> the reason for putting "Ajax" in the name of these tags (or,
> even worse, Java method names)?  The abstraction
> (asynchronous granular requests) is what matters, not the
> latest rubric or the particular transport protocol.

Well I had already contributed an inputSuggest to the sandbox that did
*not* use Ajax.  So the authors of this one decided to distinguish it.
 I've lost interest in the original inputSuggest, however, because its
just not very good with large lists (too slow.)  It has some good
javascript and DHTML that we can make use of in the Ajax version but
perhaps its time to abandon it.

I'm ok with dropping "ajax" from the names but you'll have to convince
a bunch of others.

> Cheers,
> Adam Winer

sean

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> [snip]
>
> > You cannot expect that you want to show the same autocomplete to every
> > user that comes in - this really is a very seldom case. You want to
> > depicture I18N, session information and user permissions just like
> > with a JSF component.
>
> I have been reading up on Craig's remoting solution for the (b) case.
> The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
> access it in your code using FacesContext.getCurrentInstance().
>
> This means that you *can* have some of the JSF goodness without the
> overhead of the lifecycle.  You can use method and value binding
> expressions as well as locale stuff.

... which is nice, but not as nice as actually having the actual
component instance.

> > Remember - the JSF framework was an outcome of seeing  the necessity
> > of componentization, state saving, etc. Why should that be any
> > different for AJAX components?
>
> Because it may be overkill in some instances.  I don't think an Ajax
> component that goes through the entire JSF lifecycle with every
> keystroke will scale very well.

Certainly not - but that's just about what we can do today.
If this could scale, you've got more options.

>  In inputSuggestAjax, the list of
> possible choices is meaningless.  It's not necessary to store in the
> state.  Only their final answer is important.

But OTOH, the component - and what model its bound to -
is of course correlated to which list of possible choices make
sense.

It'd be excellent to have:

  <t:inputSuggestAjax value="#{theValue}"
            possibleValues="#{aListOfPossibleValues}"/>

... and this is worlds simpler than setting up an XMLHttp
endpoint.  The problem is that today this simply isn't scalable;
the issue for JSF is making it so.

> I agree that more complicated components (like an AjaxTree) would need
> to worry about this.  In fact, that is a big PITA right now with tree2
> and the client side script.  You need to post back (via a cookie) your
> client side state changes so you can sync them up.

A good candidate for mixing in some component-tree-based AJAX
requests, though you'd certainly want to buffer them up
instead of sending requests on very expand/collapse, unless
you needed extra data sent across (another example of something
that's far easier to achieve with the component tree than without).

BTW, other than following existing hype conventions, what's
the reason for putting "Ajax" in the name of these tags (or,
even worse, Java method names)?  The abstraction
(asynchronous granular requests) is what matters, not the
latest rubric or the particular transport protocol.

Cheers,
Adam Winer

Re: Ajax lifecircle integration

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

[snip]

> You cannot expect that you want to show the same autocomplete to every
> user that comes in - this really is a very seldom case. You want to
> depicture I18N, session information and user permissions just like
> with a JSF component.

I have been reading up on Craig's remoting solution for the (b) case. 
The o.a.s.r.RemoteCommand sets up the FacesContext for you so you can
access it in your code using FacesContext.getCurrentInstance().

This means that you *can* have some of the JSF goodness without the
overhead of the lifecycle.  You can use method and value binding
expressions as well as locale stuff.

> Remember - the JSF framework was an outcome of seeing  the necessity
> of componentization, state saving, etc. Why should that be any
> different for AJAX components?

Because it may be overkill in some instances.  I don't think an Ajax
component that goes through the entire JSF lifecycle with every
keystroke will scale very well.  In inputSuggestAjax, the list of
possible choices is meaningless.  It's not necessary to store in the
state.  Only their final answer is important.

I agree that more complicated components (like an AjaxTree) would need
to worry about this.  In fact, that is a big PITA right now with tree2
and the client side script.  You need to post back (via a cookie) your
client side state changes so you can sync them up.

> Only exception: the performance is bad. Well, with every new
> technology, the performance was bad in the beginning when taking the
> abstraction to a new level. Then the programmers of the world worked
> hard to find remedies to this. And today, we seldom use Assembler to
> programm ;)

Ah yes but how many Java GUI programs were you writing when Java 1.0.2
was out and all you had was the crappy AWT?

> regards,
>
> Martin

sean

Re: Ajax lifecircle integration

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

IMHO, even for a small and simple inputSuggestAjax, you need to have
the full information the facesContext, the user session and the
component tree state provide to you.

You cannot expect that you want to show the same autocomplete to every
user that comes in - this really is a very seldom case. You want to
depicture I18N, session information and user permissions just like
with a JSF component.

Remember - the JSF framework was an outcome of seeing  the necessity
of componentization, state saving, etc. Why should that be any
different for AJAX components?

Only exception: the performance is bad. Well, with every new
technology, the performance was bad in the beginning when taking the
abstraction to a new level. Then the programmers of the world worked
hard to find remedies to this. And today, we seldom use Assembler to
programm ;)

regards,

Martin

On 11/11/05, Adam Winer <aw...@gmail.com> wrote:
> Jacob Hookom's also looking at just such an approach, connected
> with a ProcessingContext API of his:
>
>   http://weblogs.java.net/blog/jhook/
>
> -- Adam
>
> On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
> > >  For things that are flavour (a), you'd want to go through the lifecycle,
> > > but it could be more streamlined by only processing through the lifecycle on
> > > affected components only.
> >
> > Right and Craig mentioned that he was considering working on just such
> > a "shortened" lifecycle impl.  Perhaps we can help him.  I'm going to
> > be brushing up on my AJAX and thinking about this over the next few
> > weeks.  I'll have more to say then.
> >
> > >  Travis
> >
> > sean
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

Jacob Hookom's also looking at just such an approach, connected
with a ProcessingContext API of his:

  http://weblogs.java.net/blog/jhook/

-- Adam

On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
> >  For things that are flavour (a), you'd want to go through the lifecycle,
> > but it could be more streamlined by only processing through the lifecycle on
> > affected components only.
>
> Right and Craig mentioned that he was considering working on just such
> a "shortened" lifecycle impl.  Perhaps we can help him.  I'm going to
> be brushing up on my AJAX and thinking about this over the next few
> weeks.  I'll have more to say then.
>
> >  Travis
>
> sean
>

Re: Ajax lifecircle integration

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

>  For things that are flavour (a), you'd want to go through the lifecycle,
> but it could be more streamlined by only processing through the lifecycle on
> affected components only.

Right and Craig mentioned that he was considering working on just such
a "shortened" lifecycle impl.  Perhaps we can help him.  I'm going to
be brushing up on my AJAX and thinking about this over the next few
weeks.  I'll have more to say then.

>  Travis

sean

Re: Ajax lifecircle integration

[Adam Winer <aw...@gmail.com>]

In a manner of speaking, I agree with Craig.  (b) is the most common.

But it's only the most common because it's the *easiest*.  There's a
reason why everyone's building autoSuggest, etc. components as their
first AJAX components, and that's 'cause they're simplest.

Going forward, components will very much require interacting with the
component tree, and the challenge is making that interaction as rapid
as possible.

Actually, even thinking about inputSuggest, if we all (MyFaces, JSF
EG, etc.) do our job right and make a quick roundtrip that talks to
the component tree efficient, then you would actually want to go back
to the component tree even for something basic like inputSuggest,
because the component knows its model, and it's a pain to install one
web service for every different suggestion-model if we've got a
component just sitting there that knows how to handle it for all model
instances.  It's not especially practical right now, because the
performance of a round-trip through the JSF lifecycle is too painful
for anything as granular as a single keystroke.

-- Adam


On 11/10/05, Travis Reeder <tr...@gmail.com> wrote:
> Interesting thread, but I have to disagree with Craig where he says flavour
> (b) is the most common.
>  (b) The asynchronous call is completely independent of the
>  originating view, and should be a completely separate request.
>  The only thing I can think of that would be this flavour are things like
> inputSuggest, auto update datatable, and other very simple components that
> keep some info on a page updating.  As soon as you want some interaction,
> the client and server are no longer independent and this is, in my eyes,
> definitely not a seldom occurence as Maksimenko Alexander mentions.  Flavour
> (b) things still probably need access to the FacesContext and some component
> in the tree though so perhaps these types of ajax requests can just skip
> most steps in the lifecycle and get straight to the render phase where it
> will output the Ajax response.
>
>  For things that are flavour (a), you'd want to go through the lifecycle,
> but it could be more streamlined by only processing through the lifecycle on
> affected components only.
>
>  Travis
>
>  On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
> > There was an interesting discussion on AJAX and JSF a while back.
> >
> >
> http://www.mail-archive.com/users@myfaces.apache.org/msg05862.html
> >
> > At the time I wasn't doing much AJAX so I didn't weigh in.  Now that
> > we are playing around with inputSuggestAjax I have a few notions.
> >
> > If you look back at the thread, Craig made the point that many ajax
> > requests could be considered completely separate from the view and
> > therfore could be left out of the JSF lifecycle.  I tend to agree with
> > this line of reasoning.  There are cases (like tree2) where it might
> > be more crucial to keep everything in sync on both sides but there are
> > other cases (like inputSuggestAjax) where it doesn't make sense.
> >
> > For inputSuggestAjax, why does every keystroke need to travel through
> > the JSF lifecycle?  Even if its abbreviated by a responseComplete()
> > call this is a lot of overhead.  I'm going to take a closer look over
> > the weekend at the Shale remoting stuff.  It looks promising.  At a
> > minimum I think we would want our ajax component to *optionally* plug
> > into Shale's remote framework.  Maybe I will change my mind though
> > when I get into the details ;-)
> >
> > sean
> >
> > ps. This would be an excellent topic to discuss in person sometime
> > during ApacheCon.
> >
> >
> > On 11/10/05, Volker Weber
> <users.myfaces@weber-oldenburg.de > wrote:
> > > Travis,
> > > in case of single ajaxifyed components like inputSuggest you are right,
> > > there is only the value to complete transmitted.
> > > But when replacing the content of a tabbedPanel there must at least all
> > > of the content component values transmitted and decoded into the view.
> > > I found it easyer to submit the whole form than just the needed values.
> > >
> > > But the problem is the immediate attribute, i didn't know of this
> before.
> > >
> > > Regards
> > >   Volker
> > >
> > > Travis Reeder wrote:
> > > > Martin: this is for decoding, not encoding.
> > > >
> > > > Volker: The reason it is before applyRequestValues phase is because
> you
> > > > don't get the whole form submitted, you generally only get the value
> of
> > > > a single component so firstly, this way you can apply the update to
> the
> > > > single affected component and secondly, it doesn't work because it's
> > > > expecting other form values in applyRequestValues phase which are not
> > > > present on the ajax request.
> > > >
> > > > Travis
> > > >
> > > > On 11/10/05, *Martin Marinschek* < martin.marinschek@gmail.com
> > > > <ma...@gmail.com>> wrote:
> > > >
> > > >     I still believe that encoding the AJAX component should happen in
> the
> > > >     render response phase - maybe my concept of a phase listener was
> wrong
> > > >     alltogether. Maybe we should decorate the ViewHandler to ensure
> > > >     rendering of the AJAX enabled component(s) if this is necessary -
> you
> > > >     can't skip the ViewHandler, right?
> > > >
> > > >     regards,
> > > >
> > > >     Martin
> > > >
> > > >     On 11/10/05, Mike Kienenberger < mkienenb@gmail.com
> > > >     <ma...@gmail.com>> wrote:
> > > >     > If you do it after applyRequestValues, then this code may never
> be
> > > >     > reached if there's a failing conversion or validation for a
> component
> > > >     > marked immediate=true.
> > > >     >
> > > >     > On 11/10/05, Volker Weber
> <users.myfaces@weber-oldenburg.de
> > > >     <mailto: users.myfaces@weber-oldenburg.de>>
> wrote:
> > > >     > > Hi Travis,
> > > >     > >
> > > >     > > what's the reason to do this before applyRequestValues?
> > > >     > > With this you need to call decode on the components also by
> the
> > > >     listener.
> > > >     > > I don't see a problem, exept maybe the less performance
> decoding
> > > >     > > unnessesary components, doing this after applyRequestValues.
> > > >     > >
> > > >     > > Regards
> > > >     > >
> > > >     > >   Volker
> > > >     > >
> > > >     > > Travis Reeder wrote:
> > > >     > > > This might be somewhat related to what you're trying to do,
> > > >     but I've
> > > >     > > > added the AjaxDecodePhaseListener that gets kicked off
> before
> > > >     the apply
> > > >     > > > request values phase so that it can validate and update for
> > > >     that single
> > > >     > > > component.  If an error occurs such as a validation error,
> the
> > > >     error is
> > > >     > > > sent back in the ajax request so that the message can be
> shown
> > > >     to the
> > > >     > > > user.  You can see the initial results of this on the Form
> Fields
> > > >     > > > updated dynamically through ajax examples by putting in an
> > > >     invalid date
> > > >     > > > on the date text field.
> > > >     > > >
> > > >     > > > Travis
> > > >     > > >
> > > >     > > > On 11/5/05, *Mike Kienenberger* < mkienenb@gmail.com
> > > >     <ma...@gmail.com>
> > > >     > > > <mailto: mkienenb@gmail.com <ma...@gmail.com>>>
> wrote:
> > > >     > > >
> > > >     > > >     Volker,  I don't have any answers for you.
> > > >     > > >
> > > >     > > >     However, by moving the phase listener to after the apply
> > > >     request
> > > >     > > >     values phase, you're still going to have the same issues
> with
> > > >     > > >     validation that you had with InvokeApplication since
> > > >     end-users might
> > > >     > > >     specify components as immediate=true.
> > > >     > > >
> > > >     > > >     On 11/5/05, Volker Weber
> <users.myfaces@weber-oldenburg.de
> > > >     <mailto:users.myfaces@weber-oldenburg.de >
> > > >     > > >     <mailto:
> users.myfaces@weber-oldenburg.de
> > > >     <mailto: users.myfaces@weber-oldenburg.de>>>
> wrote:
> > > >     > > >     > Hi,
> > > >     > > >     >
> > > >     > > >     > during working on ajaxifying some tobago components i
> > > >     came over some
> > > >     > > >     > issues which i like to discuss here.
> > > >     > > >     >
> > > >     > > >     > Starting with adding inputSuggestAjax functionality to
> > > >     the tc:in
> > > >     > > >     > component everything goes well with the current
> sandbox
> > > >     approach
> > > >     > > >     running
> > > >     > > >     > the AjaxPhaseListener after InvokeApplication.
> > > >     > > >     >
> > > >     > > >     > My next step was ajaxifying the server side tab
> > > >     switching of tabgroup.
> > > >     > > >     > For this in need to add the tabs content values into
> the
> > > >     request to
> > > >     > > >     > preserve them in the view. Now the problem of
> validation and
> > > >     > > >     updateModel
> > > >     > > >     > occurs: If a validation error occurs, then the rest of
> > > >     lifcircle
> > > >     > > >     > (including AjaxPhaseListener) is skipped and the whole
> > > >     page is
> > > >     > > >     rendered
> > > >     > > >     > as response where only the content of one tab was
> > > >     expected on
> > > >     > > >     client side.
> > > >     > > >     > I decided to move the Listener to after
> > > >     ApplyRequestValues phase. And
> > > >     > > >     > leave the responsibility for executing other phases
> > > >     (like updateModel
> > > >     > > >     > and Validation) to the ajaxifyed component(e.g. to the
> > > >     programmer of
> > > >     > > >     > this component).
> > > >     > > >     >
> > > >     > > >     > Some weeks ago here was the proposal to replace the
> current
> > > >     > > >     procedure in
> > > >     > > >     > AjaxPhaseListener ( uiViewRoot.findComponent
> > > >     (<ajaxId>).renderAjax() )
> > > >     > > >     > by something like processAjax() invoked on uiViewRoot.
> > > >     In my opinion
> > > >     > > >     > this makes sense because there could be more to do
> than just
> > > >     > > >     rendering.
> > > >     > > >     >
> > > >     > > >     >
> > > >     > > >     > Another problem are component specific resources like
> > > >     javascript and
> > > >     > > >     > style files (*.js and *.css). Currently they are added
> > > >     to the header
> > > >     > > >     > only if they are needed after rendering the page
> content. In
> > > >     > > >     tomahawk by
> > > >     > > >     > the ExtensionFilter, in tobago by the PageRenderer
> after the
> > > >     > > >     content was
> > > >     > > >     > rendered into a buffer. This is not possible if they
> are
> > > >     rendered
> > > >     > > >     by a
> > > >     > > >     > tabswitching ajax request, because the (html) header
> is
> > > >     not rendered
> > > >     > > >     > then. There are two solutions:
> > > >     > > >     > 1) render always all possible resources into the
> header
> > > >     (I don' like
> > > >     > > >     >    this)
> > > >     > > >     > 2) load these resources via clientside scripting (This
> > > >     is what i
> > > >     > > >     >    prefer, but i'm not sure about the best way to do
> this)
> > > >     > > >     >
> > > >     > > >     >
> > > >     > > >     > Any thougths about the best way to handle these
> problems?
> > > >     > > >     >
> > > >     > > >     > regards,
> > > >     > > >     >
> > > >     > > >     >    Volker
> > > >     > > >     >
> > > >     > > >     > --
> > > >     > > >     > Don't answer to From: address!
> > > >     > > >     > Mail to this account are droped if not recieved via
> > > >     mailinglist.
> > > >     > > >     > To contact me direct create the mail address by
> > > >     > > >     > concatenating my forename to my senders domain.
> > > >     > > >     >
> > > >     > > >     >
> > > >     > > >
> > > >     > > >
> > > >     > >
> > > >     > > --
> > > >     > > Don't answer to From: address!
> > > >     > > Mail to this account are droped if not recieved via
> mailinglist.
> > > >     > > To contact me direct create the mail address by
> > > >     > > concatenating my forename to my senders domain.
> > > >     > >
> > > >     >
> > > >
> > > >
> > > >     --
> > > >
> > > >     http://www.irian.at
> > > >
> > > >     Your JSF powerhouse -
> > > >     JSF Consulting, Development and
> > > >     Courses in English and German
> > > >
> > > >     Professional Support for Apache MyFaces
> > > >
> > > >
> > >
> > > --
> > > Don't answer to From: address!
> > > Mail to this account are droped if not recieved via mailinglist.
> > > To contact me direct create the mail address by
> > > concatenating my forename to my senders domain.
> > >
> >
>
>

Re: Ajax lifecircle integration

[Travis Reeder <tr...@gmail.com>]

Interesting thread, but I have to disagree with Craig where he says flavour
(b) is the most common.

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

The only thing I can think of that would be this flavour are things like
inputSuggest, auto update datatable, and other very simple components that
keep some info on a page updating. As soon as you want some interaction, the
client and server are no longer independent and this is, in my eyes,
definitely not a seldom occurence as Maksimenko Alexander mentions. Flavour
(b) things still probably need access to the FacesContext and some component
in the tree though so perhaps these types of ajax requests can just skip
most steps in the lifecycle and get straight to the render phase where it
will output the Ajax response.

For things that are flavour (a), you'd want to go through the lifecycle, but
it could be more streamlined by only processing through the lifecycle on
affected components only.

Travis

On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
>
> There was an interesting discussion on AJAX and JSF a while back.
>
> http://www.mail-archive.com/users@myfaces.apache.org/msg05862.html
>
> At the time I wasn't doing much AJAX so I didn't weigh in. Now that
> we are playing around with inputSuggestAjax I have a few notions.
>
> If you look back at the thread, Craig made the point that many ajax
> requests could be considered completely separate from the view and
> therfore could be left out of the JSF lifecycle. I tend to agree with
> this line of reasoning. There are cases (like tree2) where it might
> be more crucial to keep everything in sync on both sides but there are
> other cases (like inputSuggestAjax) where it doesn't make sense.
>
> For inputSuggestAjax, why does every keystroke need to travel through
> the JSF lifecycle? Even if its abbreviated by a responseComplete()
> call this is a lot of overhead. I'm going to take a closer look over
> the weekend at the Shale remoting stuff. It looks promising. At a
> minimum I think we would want our ajax component to *optionally* plug
> into Shale's remote framework. Maybe I will change my mind though
> when I get into the details ;-)
>
> sean
>
> ps. This would be an excellent topic to discuss in person sometime
> during ApacheCon.
>
>
> On 11/10/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Travis,
> > in case of single ajaxifyed components like inputSuggest you are right,
> > there is only the value to complete transmitted.
> > But when replacing the content of a tabbedPanel there must at least all
> > of the content component values transmitted and decoded into the view.
> > I found it easyer to submit the whole form than just the needed values.
> >
> > But the problem is the immediate attribute, i didn't know of this
> before.
> >
> > Regards
> > Volker
> >
> > Travis Reeder wrote:
> > > Martin: this is for decoding, not encoding.
> > >
> > > Volker: The reason it is before applyRequestValues phase is because
> you
> > > don't get the whole form submitted, you generally only get the value
> of
> > > a single component so firstly, this way you can apply the update to
> the
> > > single affected component and secondly, it doesn't work because it's
> > > expecting other form values in applyRequestValues phase which are not
> > > present on the ajax request.
> > >
> > > Travis
> > >
> > > On 11/10/05, *Martin Marinschek* <martin.marinschek@gmail.com
> > > <ma...@gmail.com>> wrote:
> > >
> > > I still believe that encoding the AJAX component should happen in the
> > > render response phase - maybe my concept of a phase listener was wrong
> > > alltogether. Maybe we should decorate the ViewHandler to ensure
> > > rendering of the AJAX enabled component(s) if this is necessary - you
> > > can't skip the ViewHandler, right?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 11/10/05, Mike Kienenberger <mkienenb@gmail.com
> > > <ma...@gmail.com>> wrote:
> > > > If you do it after applyRequestValues, then this code may never be
> > > > reached if there's a failing conversion or validation for a
> component
> > > > marked immediate=true.
> > > >
> > > > On 11/10/05, Volker Weber <users.myfaces@weber-oldenburg.de
> > > <ma...@weber-oldenburg.de>> wrote:
> > > > > Hi Travis,
> > > > >
> > > > > what's the reason to do this before applyRequestValues?
> > > > > With this you need to call decode on the components also by the
> > > listener.
> > > > > I don't see a problem, exept maybe the less performance decoding
> > > > > unnessesary components, doing this after applyRequestValues.
> > > > >
> > > > > Regards
> > > > >
> > > > > Volker
> > > > >
> > > > > Travis Reeder wrote:
> > > > > > This might be somewhat related to what you're trying to do,
> > > but I've
> > > > > > added the AjaxDecodePhaseListener that gets kicked off before
> > > the apply
> > > > > > request values phase so that it can validate and update for
> > > that single
> > > > > > component. If an error occurs such as a validation error, the
> > > error is
> > > > > > sent back in the ajax request so that the message can be shown
> > > to the
> > > > > > user. You can see the initial results of this on the Form Fields
> > > > > > updated dynamically through ajax examples by putting in an
> > > invalid date
> > > > > > on the date text field.
> > > > > >
> > > > > > Travis
> > > > > >
> > > > > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> > > <ma...@gmail.com>
> > > > > > <mailto: mkienenb@gmail.com <ma...@gmail.com>>> wrote:
> > > > > >
> > > > > > Volker, I don't have any answers for you.
> > > > > >
> > > > > > However, by moving the phase listener to after the apply
> > > request
> > > > > > values phase, you're still going to have the same issues with
> > > > > > validation that you had with InvokeApplication since
> > > end-users might
> > > > > > specify components as immediate=true.
> > > > > >
> > > > > > On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
> > > <ma...@weber-oldenburg.de>
> > > > > > <mailto: users.myfaces@weber-oldenburg.de
> > > <ma...@weber-oldenburg.de>>> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > during working on ajaxifying some tobago components i
> > > came over some
> > > > > > > issues which i like to discuss here.
> > > > > > >
> > > > > > > Starting with adding inputSuggestAjax functionality to
> > > the tc:in
> > > > > > > component everything goes well with the current sandbox
> > > approach
> > > > > > running
> > > > > > > the AjaxPhaseListener after InvokeApplication.
> > > > > > >
> > > > > > > My next step was ajaxifying the server side tab
> > > switching of tabgroup.
> > > > > > > For this in need to add the tabs content values into the
> > > request to
> > > > > > > preserve them in the view. Now the problem of validation and
> > > > > > updateModel
> > > > > > > occurs: If a validation error occurs, then the rest of
> > > lifcircle
> > > > > > > (including AjaxPhaseListener) is skipped and the whole
> > > page is
> > > > > > rendered
> > > > > > > as response where only the content of one tab was
> > > expected on
> > > > > > client side.
> > > > > > > I decided to move the Listener to after
> > > ApplyRequestValues phase. And
> > > > > > > leave the responsibility for executing other phases
> > > (like updateModel
> > > > > > > and Validation) to the ajaxifyed component(e.g. to the
> > > programmer of
> > > > > > > this component).
> > > > > > >
> > > > > > > Some weeks ago here was the proposal to replace the current
> > > > > > procedure in
> > > > > > > AjaxPhaseListener ( uiViewRoot.findComponent
> > > (<ajaxId>).renderAjax() )
> > > > > > > by something like processAjax() invoked on uiViewRoot.
> > > In my opinion
> > > > > > > this makes sense because there could be more to do than just
> > > > > > rendering.
> > > > > > >
> > > > > > >
> > > > > > > Another problem are component specific resources like
> > > javascript and
> > > > > > > style files (*.js and *.css). Currently they are added
> > > to the header
> > > > > > > only if they are needed after rendering the page content. In
> > > > > > tomahawk by
> > > > > > > the ExtensionFilter, in tobago by the PageRenderer after the
> > > > > > content was
> > > > > > > rendered into a buffer. This is not possible if they are
> > > rendered
> > > > > > by a
> > > > > > > tabswitching ajax request, because the (html) header is
> > > not rendered
> > > > > > > then. There are two solutions:
> > > > > > > 1) render always all possible resources into the header
> > > (I don' like
> > > > > > > this)
> > > > > > > 2) load these resources via clientside scripting (This
> > > is what i
> > > > > > > prefer, but i'm not sure about the best way to do this)
> > > > > > >
> > > > > > >
> > > > > > > Any thougths about the best way to handle these problems?
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Volker
> > > > > > >
> > > > > > > --
> > > > > > > Don't answer to From: address!
> > > > > > > Mail to this account are droped if not recieved via
> > > mailinglist.
> > > > > > > To contact me direct create the mail address by
> > > > > > > concatenating my forename to my senders domain.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Don't answer to From: address!
> > > > > Mail to this account are droped if not recieved via mailinglist.
> > > > > To contact me direct create the mail address by
> > > > > concatenating my forename to my senders domain.
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
>

Re: Ajax lifecircle integration

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

There was an interesting discussion on AJAX and JSF a while back.

http://www.mail-archive.com/users@myfaces.apache.org/msg05862.html

At the time I wasn't doing much AJAX so I didn't weigh in.  Now that
we are playing around with inputSuggestAjax I have a few notions.

If you look back at the thread, Craig made the point that many ajax
requests could be considered completely separate from the view and
therfore could be left out of the JSF lifecycle.  I tend to agree with
this line of reasoning.  There are cases (like tree2) where it might
be more crucial to keep everything in sync on both sides but there are
other cases (like inputSuggestAjax) where it doesn't make sense.

For inputSuggestAjax, why does every keystroke need to travel through
the JSF lifecycle?  Even if its abbreviated by a responseComplete()
call this is a lot of overhead.  I'm going to take a closer look over
the weekend at the Shale remoting stuff.  It looks promising.  At a
minimum I think we would want our ajax component to *optionally* plug
into Shale's remote framework.  Maybe I will change my mind though
when I get into the details ;-)

sean

ps. This would be an excellent topic to discuss in person sometime
during ApacheCon.


On 11/10/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> Travis,
> in case of single ajaxifyed components like inputSuggest you are right,
> there is only the value to complete transmitted.
> But when replacing the content of a tabbedPanel there must at least all
> of the content component values transmitted and decoded into the view.
> I found it easyer to submit the whole form than just the needed values.
>
> But the problem is the immediate attribute, i didn't know of this before.
>
> Regards
>   Volker
>
> Travis Reeder wrote:
> > Martin: this is for decoding, not encoding.
> >
> > Volker: The reason it is before applyRequestValues phase is because you
> > don't get the whole form submitted, you generally only get the value of
> > a single component so firstly, this way you can apply the update to the
> > single affected component and secondly, it doesn't work because it's
> > expecting other form values in applyRequestValues phase which are not
> > present on the ajax request.
> >
> > Travis
> >
> > On 11/10/05, *Martin Marinschek* <martin.marinschek@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >     I still believe that encoding the AJAX component should happen in the
> >     render response phase - maybe my concept of a phase listener was wrong
> >     alltogether. Maybe we should decorate the ViewHandler to ensure
> >     rendering of the AJAX enabled component(s) if this is necessary - you
> >     can't skip the ViewHandler, right?
> >
> >     regards,
> >
> >     Martin
> >
> >     On 11/10/05, Mike Kienenberger <mkienenb@gmail.com
> >     <ma...@gmail.com>> wrote:
> >     > If you do it after applyRequestValues, then this code may never be
> >     > reached if there's a failing conversion or validation for a component
> >     > marked immediate=true.
> >     >
> >     > On 11/10/05, Volker Weber <users.myfaces@weber-oldenburg.de
> >     <ma...@weber-oldenburg.de>> wrote:
> >     > > Hi Travis,
> >     > >
> >     > > what's the reason to do this before applyRequestValues?
> >     > > With this you need to call decode on the components also by the
> >     listener.
> >     > > I don't see a problem, exept maybe the less performance decoding
> >     > > unnessesary components, doing this after applyRequestValues.
> >     > >
> >     > > Regards
> >     > >
> >     > >   Volker
> >     > >
> >     > > Travis Reeder wrote:
> >     > > > This might be somewhat related to what you're trying to do,
> >     but I've
> >     > > > added the AjaxDecodePhaseListener that gets kicked off before
> >     the apply
> >     > > > request values phase so that it can validate and update for
> >     that single
> >     > > > component.  If an error occurs such as a validation error, the
> >     error is
> >     > > > sent back in the ajax request so that the message can be shown
> >     to the
> >     > > > user.  You can see the initial results of this on the Form Fields
> >     > > > updated dynamically through ajax examples by putting in an
> >     invalid date
> >     > > > on the date text field.
> >     > > >
> >     > > > Travis
> >     > > >
> >     > > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> >     <ma...@gmail.com>
> >     > > > <mailto: mkienenb@gmail.com <ma...@gmail.com>>> wrote:
> >     > > >
> >     > > >     Volker,  I don't have any answers for you.
> >     > > >
> >     > > >     However, by moving the phase listener to after the apply
> >     request
> >     > > >     values phase, you're still going to have the same issues with
> >     > > >     validation that you had with InvokeApplication since
> >     end-users might
> >     > > >     specify components as immediate=true.
> >     > > >
> >     > > >     On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
> >     <ma...@weber-oldenburg.de>
> >     > > >     <mailto: users.myfaces@weber-oldenburg.de
> >     <ma...@weber-oldenburg.de>>> wrote:
> >     > > >     > Hi,
> >     > > >     >
> >     > > >     > during working on ajaxifying some tobago components i
> >     came over some
> >     > > >     > issues which i like to discuss here.
> >     > > >     >
> >     > > >     > Starting with adding inputSuggestAjax functionality to
> >     the tc:in
> >     > > >     > component everything goes well with the current sandbox
> >     approach
> >     > > >     running
> >     > > >     > the AjaxPhaseListener after InvokeApplication.
> >     > > >     >
> >     > > >     > My next step was ajaxifying the server side tab
> >     switching of tabgroup.
> >     > > >     > For this in need to add the tabs content values into the
> >     request to
> >     > > >     > preserve them in the view. Now the problem of validation and
> >     > > >     updateModel
> >     > > >     > occurs: If a validation error occurs, then the rest of
> >     lifcircle
> >     > > >     > (including AjaxPhaseListener) is skipped and the whole
> >     page is
> >     > > >     rendered
> >     > > >     > as response where only the content of one tab was
> >     expected on
> >     > > >     client side.
> >     > > >     > I decided to move the Listener to after
> >     ApplyRequestValues phase. And
> >     > > >     > leave the responsibility for executing other phases
> >     (like updateModel
> >     > > >     > and Validation) to the ajaxifyed component(e.g. to the
> >     programmer of
> >     > > >     > this component).
> >     > > >     >
> >     > > >     > Some weeks ago here was the proposal to replace the current
> >     > > >     procedure in
> >     > > >     > AjaxPhaseListener ( uiViewRoot.findComponent
> >     (<ajaxId>).renderAjax() )
> >     > > >     > by something like processAjax() invoked on uiViewRoot.
> >     In my opinion
> >     > > >     > this makes sense because there could be more to do than just
> >     > > >     rendering.
> >     > > >     >
> >     > > >     >
> >     > > >     > Another problem are component specific resources like
> >     javascript and
> >     > > >     > style files (*.js and *.css). Currently they are added
> >     to the header
> >     > > >     > only if they are needed after rendering the page content. In
> >     > > >     tomahawk by
> >     > > >     > the ExtensionFilter, in tobago by the PageRenderer after the
> >     > > >     content was
> >     > > >     > rendered into a buffer. This is not possible if they are
> >     rendered
> >     > > >     by a
> >     > > >     > tabswitching ajax request, because the (html) header is
> >     not rendered
> >     > > >     > then. There are two solutions:
> >     > > >     > 1) render always all possible resources into the header
> >     (I don' like
> >     > > >     >    this)
> >     > > >     > 2) load these resources via clientside scripting (This
> >     is what i
> >     > > >     >    prefer, but i'm not sure about the best way to do this)
> >     > > >     >
> >     > > >     >
> >     > > >     > Any thougths about the best way to handle these problems?
> >     > > >     >
> >     > > >     > regards,
> >     > > >     >
> >     > > >     >    Volker
> >     > > >     >
> >     > > >     > --
> >     > > >     > Don't answer to From: address!
> >     > > >     > Mail to this account are droped if not recieved via
> >     mailinglist.
> >     > > >     > To contact me direct create the mail address by
> >     > > >     > concatenating my forename to my senders domain.
> >     > > >     >
> >     > > >     >
> >     > > >
> >     > > >
> >     > >
> >     > > --
> >     > > Don't answer to From: address!
> >     > > Mail to this account are droped if not recieved via mailinglist.
> >     > > To contact me direct create the mail address by
> >     > > concatenating my forename to my senders domain.
> >     > >
> >     >
> >
> >
> >     --
> >
> >     http://www.irian.at
> >
> >     Your JSF powerhouse -
> >     JSF Consulting, Development and
> >     Courses in English and German
> >
> >     Professional Support for Apache MyFaces
> >
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>

Re: Ajax lifecircle integration

[Volker Weber <us...@weber-oldenburg.de>]

Travis,
in case of single ajaxifyed components like inputSuggest you are right,
there is only the value to complete transmitted.
But when replacing the content of a tabbedPanel there must at least all
of the content component values transmitted and decoded into the view.
I found it easyer to submit the whole form than just the needed values.

But the problem is the immediate attribute, i didn't know of this before.

Regards
  Volker

Travis Reeder wrote:
> Martin: this is for decoding, not encoding.
> 
> Volker: The reason it is before applyRequestValues phase is because you
> don't get the whole form submitted, you generally only get the value of
> a single component so firstly, this way you can apply the update to the
> single affected component and secondly, it doesn't work because it's
> expecting other form values in applyRequestValues phase which are not
> present on the ajax request. 
> 
> Travis
> 
> On 11/10/05, *Martin Marinschek* <martin.marinschek@gmail.com
> <ma...@gmail.com>> wrote:
> 
>     I still believe that encoding the AJAX component should happen in the
>     render response phase - maybe my concept of a phase listener was wrong
>     alltogether. Maybe we should decorate the ViewHandler to ensure
>     rendering of the AJAX enabled component(s) if this is necessary - you
>     can't skip the ViewHandler, right?
> 
>     regards,
> 
>     Martin
> 
>     On 11/10/05, Mike Kienenberger <mkienenb@gmail.com
>     <ma...@gmail.com>> wrote:
>     > If you do it after applyRequestValues, then this code may never be
>     > reached if there's a failing conversion or validation for a component
>     > marked immediate=true.
>     >
>     > On 11/10/05, Volker Weber <users.myfaces@weber-oldenburg.de
>     <ma...@weber-oldenburg.de>> wrote:
>     > > Hi Travis,
>     > >
>     > > what's the reason to do this before applyRequestValues?
>     > > With this you need to call decode on the components also by the
>     listener.
>     > > I don't see a problem, exept maybe the less performance decoding
>     > > unnessesary components, doing this after applyRequestValues.
>     > >
>     > > Regards
>     > >
>     > >   Volker
>     > >
>     > > Travis Reeder wrote:
>     > > > This might be somewhat related to what you're trying to do,
>     but I've
>     > > > added the AjaxDecodePhaseListener that gets kicked off before
>     the apply
>     > > > request values phase so that it can validate and update for
>     that single
>     > > > component.  If an error occurs such as a validation error, the
>     error is
>     > > > sent back in the ajax request so that the message can be shown
>     to the
>     > > > user.  You can see the initial results of this on the Form Fields
>     > > > updated dynamically through ajax examples by putting in an
>     invalid date
>     > > > on the date text field.
>     > > >
>     > > > Travis
>     > > >
>     > > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
>     <ma...@gmail.com>
>     > > > <mailto: mkienenb@gmail.com <ma...@gmail.com>>> wrote:
>     > > >
>     > > >     Volker,  I don't have any answers for you.
>     > > >
>     > > >     However, by moving the phase listener to after the apply
>     request
>     > > >     values phase, you're still going to have the same issues with
>     > > >     validation that you had with InvokeApplication since
>     end-users might
>     > > >     specify components as immediate=true.
>     > > >
>     > > >     On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
>     <ma...@weber-oldenburg.de>
>     > > >     <mailto: users.myfaces@weber-oldenburg.de
>     <ma...@weber-oldenburg.de>>> wrote:
>     > > >     > Hi,
>     > > >     >
>     > > >     > during working on ajaxifying some tobago components i
>     came over some
>     > > >     > issues which i like to discuss here.
>     > > >     >
>     > > >     > Starting with adding inputSuggestAjax functionality to
>     the tc:in
>     > > >     > component everything goes well with the current sandbox
>     approach
>     > > >     running
>     > > >     > the AjaxPhaseListener after InvokeApplication.
>     > > >     >
>     > > >     > My next step was ajaxifying the server side tab
>     switching of tabgroup.
>     > > >     > For this in need to add the tabs content values into the
>     request to
>     > > >     > preserve them in the view. Now the problem of validation and
>     > > >     updateModel
>     > > >     > occurs: If a validation error occurs, then the rest of
>     lifcircle
>     > > >     > (including AjaxPhaseListener) is skipped and the whole
>     page is
>     > > >     rendered
>     > > >     > as response where only the content of one tab was
>     expected on
>     > > >     client side.
>     > > >     > I decided to move the Listener to after
>     ApplyRequestValues phase. And
>     > > >     > leave the responsibility for executing other phases
>     (like updateModel
>     > > >     > and Validation) to the ajaxifyed component(e.g. to the
>     programmer of
>     > > >     > this component).
>     > > >     >
>     > > >     > Some weeks ago here was the proposal to replace the current
>     > > >     procedure in
>     > > >     > AjaxPhaseListener ( uiViewRoot.findComponent
>     (<ajaxId>).renderAjax() )
>     > > >     > by something like processAjax() invoked on uiViewRoot.
>     In my opinion
>     > > >     > this makes sense because there could be more to do than just
>     > > >     rendering.
>     > > >     >
>     > > >     >
>     > > >     > Another problem are component specific resources like
>     javascript and
>     > > >     > style files (*.js and *.css). Currently they are added
>     to the header
>     > > >     > only if they are needed after rendering the page content. In
>     > > >     tomahawk by
>     > > >     > the ExtensionFilter, in tobago by the PageRenderer after the
>     > > >     content was
>     > > >     > rendered into a buffer. This is not possible if they are
>     rendered
>     > > >     by a
>     > > >     > tabswitching ajax request, because the (html) header is
>     not rendered
>     > > >     > then. There are two solutions:
>     > > >     > 1) render always all possible resources into the header
>     (I don' like
>     > > >     >    this)
>     > > >     > 2) load these resources via clientside scripting (This
>     is what i
>     > > >     >    prefer, but i'm not sure about the best way to do this)
>     > > >     >
>     > > >     >
>     > > >     > Any thougths about the best way to handle these problems?
>     > > >     >
>     > > >     > regards,
>     > > >     >
>     > > >     >    Volker
>     > > >     >
>     > > >     > --
>     > > >     > Don't answer to From: address!
>     > > >     > Mail to this account are droped if not recieved via
>     mailinglist.
>     > > >     > To contact me direct create the mail address by
>     > > >     > concatenating my forename to my senders domain.
>     > > >     >
>     > > >     >
>     > > >
>     > > >
>     > >
>     > > --
>     > > Don't answer to From: address!
>     > > Mail to this account are droped if not recieved via mailinglist.
>     > > To contact me direct create the mail address by
>     > > concatenating my forename to my senders domain.
>     > >
>     >
> 
> 
>     --
> 
>     http://www.irian.at
> 
>     Your JSF powerhouse -
>     JSF Consulting, Development and
>     Courses in English and German
> 
>     Professional Support for Apache MyFaces
> 
> 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: Ajax lifecircle integration

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

Yes, sorry, I was still talking about encoding.

Haven't thought much about decoding so far ;)

regards,

Martin

On 11/10/05, Travis Reeder <tr...@gmail.com> wrote:
> Martin: this is for decoding, not encoding.
>
>  Volker: The reason it is before applyRequestValues phase is because you
> don't get the whole form submitted, you generally only get the value of a
> single component so firstly, this way you can apply the update to the single
> affected component and secondly, it doesn't work because it's expecting
> other form values in applyRequestValues phase which are not present on the
> ajax request.
>
>  Travis
>
>
> On 11/10/05, Martin Marinschek <ma...@gmail.com> wrote:
> > I still believe that encoding the AJAX component should happen in the
> > render response phase - maybe my concept of a phase listener was wrong
> > alltogether. Maybe we should decorate the ViewHandler to ensure
> > rendering of the AJAX enabled component(s) if this is necessary - you
> > can't skip the ViewHandler, right?
> >
> > regards,
> >
> > Martin
> >
> > On 11/10/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > > If you do it after applyRequestValues, then this code may never be
> > > reached if there's a failing conversion or validation for a component
> > > marked immediate=true.
> > >
> > > On 11/10/05, Volker Weber
> <users.myfaces@weber-oldenburg.de > wrote:
> > > > Hi Travis,
> > > >
> > > > what's the reason to do this before applyRequestValues?
> > > > With this you need to call decode on the components also by the
> listener.
> > > > I don't see a problem, exept maybe the less performance decoding
> > > > unnessesary components, doing this after applyRequestValues.
> > > >
> > > > Regards
> > > >
> > > >   Volker
> > > >
> > > > Travis Reeder wrote:
> > > > > This might be somewhat related to what you're trying to do, but I've
> > > > > added the AjaxDecodePhaseListener that gets kicked off before the
> apply
> > > > > request values phase so that it can validate and update for that
> single
> > > > > component.  If an error occurs such as a validation error, the error
> is
> > > > > sent back in the ajax request so that the message can be shown to
> the
> > > > > user.  You can see the initial results of this on the Form Fields
> > > > > updated dynamically through ajax examples by putting in an invalid
> date
> > > > > on the date text field.
> > > > >
> > > > > Travis
> > > > >
> > > > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> > > > > <mailto: mkienenb@gmail.com>> wrote:
> > > > >
> > > > >     Volker,  I don't have any answers for you.
> > > > >
> > > > >     However, by moving the phase listener to after the apply request
> > > > >     values phase, you're still going to have the same issues with
> > > > >     validation that you had with InvokeApplication since end-users
> might
> > > > >     specify components as immediate=true.
> > > > >
> > > > >     On 11/5/05, Volker Weber
> <users.myfaces@weber-oldenburg.de
> > > > >     <mailto: users.myfaces@weber-oldenburg.de>>
> wrote:
> > > > >     > Hi,
> > > > >     >
> > > > >     > during working on ajaxifying some tobago components i came
> over some
> > > > >     > issues which i like to discuss here.
> > > > >     >
> > > > >     > Starting with adding inputSuggestAjax functionality to the
> tc:in
> > > > >     > component everything goes well with the current sandbox
> approach
> > > > >     running
> > > > >     > the AjaxPhaseListener after InvokeApplication.
> > > > >     >
> > > > >     > My next step was ajaxifying the server side tab switching of
> tabgroup.
> > > > >     > For this in need to add the tabs content values into the
> request to
> > > > >     > preserve them in the view. Now the problem of validation and
> > > > >     updateModel
> > > > >     > occurs: If a validation error occurs, then the rest of
> lifcircle
> > > > >     > (including AjaxPhaseListener) is skipped and the whole page is
> > > > >     rendered
> > > > >     > as response where only the content of one tab was expected on
> > > > >     client side.
> > > > >     > I decided to move the Listener to after ApplyRequestValues
> phase. And
> > > > >     > leave the responsibility for executing other phases (like
> updateModel
> > > > >     > and Validation) to the ajaxifyed component(e.g. to the
> programmer of
> > > > >     > this component).
> > > > >     >
> > > > >     > Some weeks ago here was the proposal to replace the current
> > > > >     procedure in
> > > > >     > AjaxPhaseListener ( uiViewRoot.findComponent
> (<ajaxId>).renderAjax() )
> > > > >     > by something like processAjax() invoked on uiViewRoot. In my
> opinion
> > > > >     > this makes sense because there could be more to do than just
> > > > >     rendering.
> > > > >     >
> > > > >     >
> > > > >     > Another problem are component specific resources like
> javascript and
> > > > >     > style files (*.js and *.css). Currently they are added to the
> header
> > > > >     > only if they are needed after rendering the page content. In
> > > > >     tomahawk by
> > > > >     > the ExtensionFilter, in tobago by the PageRenderer after the
> > > > >     content was
> > > > >     > rendered into a buffer. This is not possible if they are
> rendered
> > > > >     by a
> > > > >     > tabswitching ajax request, because the (html) header is not
> rendered
> > > > >     > then. There are two solutions:
> > > > >     > 1) render always all possible resources into the header (I
> don' like
> > > > >     >    this)
> > > > >     > 2) load these resources via clientside scripting (This is what
> i
> > > > >     >    prefer, but i'm not sure about the best way to do this)
> > > > >     >
> > > > >     >
> > > > >     > Any thougths about the best way to handle these problems?
> > > > >     >
> > > > >     > regards,
> > > > >     >
> > > > >     >    Volker
> > > > >     >
> > > > >     > --
> > > > >     > Don't answer to From: address!
> > > > >     > Mail to this account are droped if not recieved via
> mailinglist.
> > > > >     > To contact me direct create the mail address by
> > > > >     > concatenating my forename to my senders domain.
> > > > >     >
> > > > >     >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Don't answer to From: address!
> > > > Mail to this account are droped if not recieved via mailinglist.
> > > > To contact me direct create the mail address by
> > > > concatenating my forename to my senders domain.
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

[Travis Reeder <tr...@gmail.com>]

Martin: this is for decoding, not encoding.

Volker: The reason it is before applyRequestValues phase is because you
don't get the whole form submitted, you generally only get the value of a
single component so firstly, this way you can apply the update to the single
affected component and secondly, it doesn't work because it's expecting
other form values in applyRequestValues phase which are not present on the
ajax request.

Travis

On 11/10/05, Martin Marinschek <ma...@gmail.com> wrote:
>
> I still believe that encoding the AJAX component should happen in the
> render response phase - maybe my concept of a phase listener was wrong
> alltogether. Maybe we should decorate the ViewHandler to ensure
> rendering of the AJAX enabled component(s) if this is necessary - you
> can't skip the ViewHandler, right?
>
> regards,
>
> Martin
>
> On 11/10/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > If you do it after applyRequestValues, then this code may never be
> > reached if there's a failing conversion or validation for a component
> > marked immediate=true.
> >
> > On 11/10/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> > > Hi Travis,
> > >
> > > what's the reason to do this before applyRequestValues?
> > > With this you need to call decode on the components also by the
> listener.
> > > I don't see a problem, exept maybe the less performance decoding
> > > unnessesary components, doing this after applyRequestValues.
> > >
> > > Regards
> > >
> > > Volker
> > >
> > > Travis Reeder wrote:
> > > > This might be somewhat related to what you're trying to do, but I've
> > > > added the AjaxDecodePhaseListener that gets kicked off before the
> apply
> > > > request values phase so that it can validate and update for that
> single
> > > > component. If an error occurs such as a validation error, the error
> is
> > > > sent back in the ajax request so that the message can be shown to
> the
> > > > user. You can see the initial results of this on the Form Fields
> > > > updated dynamically through ajax examples by putting in an invalid
> date
> > > > on the date text field.
> > > >
> > > > Travis
> > > >
> > > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> > > > <ma...@gmail.com>> wrote:
> > > >
> > > > Volker, I don't have any answers for you.
> > > >
> > > > However, by moving the phase listener to after the apply request
> > > > values phase, you're still going to have the same issues with
> > > > validation that you had with InvokeApplication since end-users might
> > > > specify components as immediate=true.
> > > >
> > > > On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
> > > > <ma...@weber-oldenburg.de>> wrote:
> > > > > Hi,
> > > > >
> > > > > during working on ajaxifying some tobago components i came over
> some
> > > > > issues which i like to discuss here.
> > > > >
> > > > > Starting with adding inputSuggestAjax functionality to the tc:in
> > > > > component everything goes well with the current sandbox approach
> > > > running
> > > > > the AjaxPhaseListener after InvokeApplication.
> > > > >
> > > > > My next step was ajaxifying the server side tab switching of
> tabgroup.
> > > > > For this in need to add the tabs content values into the request
> to
> > > > > preserve them in the view. Now the problem of validation and
> > > > updateModel
> > > > > occurs: If a validation error occurs, then the rest of lifcircle
> > > > > (including AjaxPhaseListener) is skipped and the whole page is
> > > > rendered
> > > > > as response where only the content of one tab was expected on
> > > > client side.
> > > > > I decided to move the Listener to after ApplyRequestValues phase.
> And
> > > > > leave the responsibility for executing other phases (like
> updateModel
> > > > > and Validation) to the ajaxifyed component(e.g. to the programmer
> of
> > > > > this component).
> > > > >
> > > > > Some weeks ago here was the proposal to replace the current
> > > > procedure in
> > > > > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax()
> )
> > > > > by something like processAjax() invoked on uiViewRoot. In my
> opinion
> > > > > this makes sense because there could be more to do than just
> > > > rendering.
> > > > >
> > > > >
> > > > > Another problem are component specific resources like javascript
> and
> > > > > style files (*.js and *.css). Currently they are added to the
> header
> > > > > only if they are needed after rendering the page content. In
> > > > tomahawk by
> > > > > the ExtensionFilter, in tobago by the PageRenderer after the
> > > > content was
> > > > > rendered into a buffer. This is not possible if they are rendered
> > > > by a
> > > > > tabswitching ajax request, because the (html) header is not
> rendered
> > > > > then. There are two solutions:
> > > > > 1) render always all possible resources into the header (I don'
> like
> > > > > this)
> > > > > 2) load these resources via clientside scripting (This is what i
> > > > > prefer, but i'm not sure about the best way to do this)
> > > > >
> > > > >
> > > > > Any thougths about the best way to handle these problems?
> > > > >
> > > > > regards,
> > > > >
> > > > > Volker
> > > > >
> > > > > --
> > > > > Don't answer to From: address!
> > > > > Mail to this account are droped if not recieved via mailinglist.
> > > > > To contact me direct create the mail address by
> > > > > concatenating my forename to my senders domain.
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Don't answer to From: address!
> > > Mail to this account are droped if not recieved via mailinglist.
> > > To contact me direct create the mail address by
> > > concatenating my forename to my senders domain.
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: Ajax lifecircle integration

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

I still believe that encoding the AJAX component should happen in the
render response phase - maybe my concept of a phase listener was wrong
alltogether. Maybe we should decorate the ViewHandler to ensure
rendering of the AJAX enabled component(s) if this is necessary - you
can't skip the ViewHandler, right?

regards,

Martin

On 11/10/05, Mike Kienenberger <mk...@gmail.com> wrote:
> If you do it after applyRequestValues, then this code may never be
> reached if there's a failing conversion or validation for a component
> marked immediate=true.
>
> On 11/10/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Hi Travis,
> >
> > what's the reason to do this before applyRequestValues?
> > With this you need to call decode on the components also by the listener.
> > I don't see a problem, exept maybe the less performance decoding
> > unnessesary components, doing this after applyRequestValues.
> >
> > Regards
> >
> >   Volker
> >
> > Travis Reeder wrote:
> > > This might be somewhat related to what you're trying to do, but I've
> > > added the AjaxDecodePhaseListener that gets kicked off before the apply
> > > request values phase so that it can validate and update for that single
> > > component.  If an error occurs such as a validation error, the error is
> > > sent back in the ajax request so that the message can be shown to the
> > > user.  You can see the initial results of this on the Form Fields
> > > updated dynamically through ajax examples by putting in an invalid date
> > > on the date text field.
> > >
> > > Travis
> > >
> > > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> > > <ma...@gmail.com>> wrote:
> > >
> > >     Volker,  I don't have any answers for you.
> > >
> > >     However, by moving the phase listener to after the apply request
> > >     values phase, you're still going to have the same issues with
> > >     validation that you had with InvokeApplication since end-users might
> > >     specify components as immediate=true.
> > >
> > >     On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
> > >     <ma...@weber-oldenburg.de>> wrote:
> > >     > Hi,
> > >     >
> > >     > during working on ajaxifying some tobago components i came over some
> > >     > issues which i like to discuss here.
> > >     >
> > >     > Starting with adding inputSuggestAjax functionality to the tc:in
> > >     > component everything goes well with the current sandbox approach
> > >     running
> > >     > the AjaxPhaseListener after InvokeApplication.
> > >     >
> > >     > My next step was ajaxifying the server side tab switching of tabgroup.
> > >     > For this in need to add the tabs content values into the request to
> > >     > preserve them in the view. Now the problem of validation and
> > >     updateModel
> > >     > occurs: If a validation error occurs, then the rest of lifcircle
> > >     > (including AjaxPhaseListener) is skipped and the whole page is
> > >     rendered
> > >     > as response where only the content of one tab was expected on
> > >     client side.
> > >     > I decided to move the Listener to after ApplyRequestValues phase. And
> > >     > leave the responsibility for executing other phases (like updateModel
> > >     > and Validation) to the ajaxifyed component(e.g. to the programmer of
> > >     > this component).
> > >     >
> > >     > Some weeks ago here was the proposal to replace the current
> > >     procedure in
> > >     > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> > >     > by something like processAjax() invoked on uiViewRoot. In my opinion
> > >     > this makes sense because there could be more to do than just
> > >     rendering.
> > >     >
> > >     >
> > >     > Another problem are component specific resources like javascript and
> > >     > style files (*.js and *.css). Currently they are added to the header
> > >     > only if they are needed after rendering the page content. In
> > >     tomahawk by
> > >     > the ExtensionFilter, in tobago by the PageRenderer after the
> > >     content was
> > >     > rendered into a buffer. This is not possible if they are rendered
> > >     by a
> > >     > tabswitching ajax request, because the (html) header is not rendered
> > >     > then. There are two solutions:
> > >     > 1) render always all possible resources into the header (I don' like
> > >     >    this)
> > >     > 2) load these resources via clientside scripting (This is what i
> > >     >    prefer, but i'm not sure about the best way to do this)
> > >     >
> > >     >
> > >     > Any thougths about the best way to handle these problems?
> > >     >
> > >     > regards,
> > >     >
> > >     >    Volker
> > >     >
> > >     > --
> > >     > Don't answer to From: address!
> > >     > Mail to this account are droped if not recieved via mailinglist.
> > >     > To contact me direct create the mail address by
> > >     > concatenating my forename to my senders domain.
> > >     >
> > >     >
> > >
> > >
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Ajax lifecircle integration

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

If you do it after applyRequestValues, then this code may never be
reached if there's a failing conversion or validation for a component
marked immediate=true.

On 11/10/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi Travis,
>
> what's the reason to do this before applyRequestValues?
> With this you need to call decode on the components also by the listener.
> I don't see a problem, exept maybe the less performance decoding
> unnessesary components, doing this after applyRequestValues.
>
> Regards
>
>   Volker
>
> Travis Reeder wrote:
> > This might be somewhat related to what you're trying to do, but I've
> > added the AjaxDecodePhaseListener that gets kicked off before the apply
> > request values phase so that it can validate and update for that single
> > component.  If an error occurs such as a validation error, the error is
> > sent back in the ajax request so that the message can be shown to the
> > user.  You can see the initial results of this on the Form Fields
> > updated dynamically through ajax examples by putting in an invalid date
> > on the date text field.
> >
> > Travis
> >
> > On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> >     Volker,  I don't have any answers for you.
> >
> >     However, by moving the phase listener to after the apply request
> >     values phase, you're still going to have the same issues with
> >     validation that you had with InvokeApplication since end-users might
> >     specify components as immediate=true.
> >
> >     On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
> >     <ma...@weber-oldenburg.de>> wrote:
> >     > Hi,
> >     >
> >     > during working on ajaxifying some tobago components i came over some
> >     > issues which i like to discuss here.
> >     >
> >     > Starting with adding inputSuggestAjax functionality to the tc:in
> >     > component everything goes well with the current sandbox approach
> >     running
> >     > the AjaxPhaseListener after InvokeApplication.
> >     >
> >     > My next step was ajaxifying the server side tab switching of tabgroup.
> >     > For this in need to add the tabs content values into the request to
> >     > preserve them in the view. Now the problem of validation and
> >     updateModel
> >     > occurs: If a validation error occurs, then the rest of lifcircle
> >     > (including AjaxPhaseListener) is skipped and the whole page is
> >     rendered
> >     > as response where only the content of one tab was expected on
> >     client side.
> >     > I decided to move the Listener to after ApplyRequestValues phase. And
> >     > leave the responsibility for executing other phases (like updateModel
> >     > and Validation) to the ajaxifyed component(e.g. to the programmer of
> >     > this component).
> >     >
> >     > Some weeks ago here was the proposal to replace the current
> >     procedure in
> >     > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> >     > by something like processAjax() invoked on uiViewRoot. In my opinion
> >     > this makes sense because there could be more to do than just
> >     rendering.
> >     >
> >     >
> >     > Another problem are component specific resources like javascript and
> >     > style files (*.js and *.css). Currently they are added to the header
> >     > only if they are needed after rendering the page content. In
> >     tomahawk by
> >     > the ExtensionFilter, in tobago by the PageRenderer after the
> >     content was
> >     > rendered into a buffer. This is not possible if they are rendered
> >     by a
> >     > tabswitching ajax request, because the (html) header is not rendered
> >     > then. There are two solutions:
> >     > 1) render always all possible resources into the header (I don' like
> >     >    this)
> >     > 2) load these resources via clientside scripting (This is what i
> >     >    prefer, but i'm not sure about the best way to do this)
> >     >
> >     >
> >     > Any thougths about the best way to handle these problems?
> >     >
> >     > regards,
> >     >
> >     >    Volker
> >     >
> >     > --
> >     > Don't answer to From: address!
> >     > Mail to this account are droped if not recieved via mailinglist.
> >     > To contact me direct create the mail address by
> >     > concatenating my forename to my senders domain.
> >     >
> >     >
> >
> >
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>

Re: Ajax lifecircle integration

[Volker Weber <us...@weber-oldenburg.de>]

Hi Travis,

what's the reason to do this before applyRequestValues?
With this you need to call decode on the components also by the listener.
I don't see a problem, exept maybe the less performance decoding
unnessesary components, doing this after applyRequestValues.

Regards

  Volker

Travis Reeder wrote:
> This might be somewhat related to what you're trying to do, but I've
> added the AjaxDecodePhaseListener that gets kicked off before the apply
> request values phase so that it can validate and update for that single
> component.  If an error occurs such as a validation error, the error is
> sent back in the ajax request so that the message can be shown to the
> user.  You can see the initial results of this on the Form Fields
> updated dynamically through ajax examples by putting in an invalid date
> on the date text field. 
> 
> Travis
> 
> On 11/5/05, *Mike Kienenberger* <mkienenb@gmail.com
> <ma...@gmail.com>> wrote:
> 
>     Volker,  I don't have any answers for you.
> 
>     However, by moving the phase listener to after the apply request
>     values phase, you're still going to have the same issues with
>     validation that you had with InvokeApplication since end-users might
>     specify components as immediate=true.
> 
>     On 11/5/05, Volker Weber <users.myfaces@weber-oldenburg.de
>     <ma...@weber-oldenburg.de>> wrote:
>     > Hi,
>     >
>     > during working on ajaxifying some tobago components i came over some
>     > issues which i like to discuss here.
>     >
>     > Starting with adding inputSuggestAjax functionality to the tc:in
>     > component everything goes well with the current sandbox approach
>     running
>     > the AjaxPhaseListener after InvokeApplication.
>     >
>     > My next step was ajaxifying the server side tab switching of tabgroup.
>     > For this in need to add the tabs content values into the request to
>     > preserve them in the view. Now the problem of validation and
>     updateModel
>     > occurs: If a validation error occurs, then the rest of lifcircle
>     > (including AjaxPhaseListener) is skipped and the whole page is
>     rendered
>     > as response where only the content of one tab was expected on
>     client side.
>     > I decided to move the Listener to after ApplyRequestValues phase. And
>     > leave the responsibility for executing other phases (like updateModel
>     > and Validation) to the ajaxifyed component(e.g. to the programmer of
>     > this component).
>     >
>     > Some weeks ago here was the proposal to replace the current
>     procedure in
>     > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
>     > by something like processAjax() invoked on uiViewRoot. In my opinion
>     > this makes sense because there could be more to do than just
>     rendering.
>     >
>     >
>     > Another problem are component specific resources like javascript and
>     > style files (*.js and *.css). Currently they are added to the header
>     > only if they are needed after rendering the page content. In
>     tomahawk by
>     > the ExtensionFilter, in tobago by the PageRenderer after the
>     content was
>     > rendered into a buffer. This is not possible if they are rendered
>     by a
>     > tabswitching ajax request, because the (html) header is not rendered
>     > then. There are two solutions:
>     > 1) render always all possible resources into the header (I don' like
>     >    this)
>     > 2) load these resources via clientside scripting (This is what i
>     >    prefer, but i'm not sure about the best way to do this)
>     >
>     >
>     > Any thougths about the best way to handle these problems?
>     >
>     > regards,
>     >
>     >    Volker
>     >
>     > --
>     > Don't answer to From: address!
>     > Mail to this account are droped if not recieved via mailinglist.
>     > To contact me direct create the mail address by
>     > concatenating my forename to my senders domain.
>     >
>     >
> 
> 

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: Ajax lifecircle integration

[Travis Reeder <tr...@gmail.com>]

This might be somewhat related to what you're trying to do, but I've added
the AjaxDecodePhaseListener that gets kicked off before the apply request
values phase so that it can validate and update for that single component.
If an error occurs such as a validation error, the error is sent back in the
ajax request so that the message can be shown to the user. You can see the
initial results of this on the Form Fields updated dynamically through ajax
examples by putting in an invalid date on the date text field.

Travis

On 11/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> Volker, I don't have any answers for you.
>
> However, by moving the phase listener to after the apply request
> values phase, you're still going to have the same issues with
> validation that you had with InvokeApplication since end-users might
> specify components as immediate=true.
>
> On 11/5/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Hi,
> >
> > during working on ajaxifying some tobago components i came over some
> > issues which i like to discuss here.
> >
> > Starting with adding inputSuggestAjax functionality to the tc:in
> > component everything goes well with the current sandbox approach running
> > the AjaxPhaseListener after InvokeApplication.
> >
> > My next step was ajaxifying the server side tab switching of tabgroup.
> > For this in need to add the tabs content values into the request to
> > preserve them in the view. Now the problem of validation and updateModel
> > occurs: If a validation error occurs, then the rest of lifcircle
> > (including AjaxPhaseListener) is skipped and the whole page is rendered
> > as response where only the content of one tab was expected on client
> side.
> > I decided to move the Listener to after ApplyRequestValues phase. And
> > leave the responsibility for executing other phases (like updateModel
> > and Validation) to the ajaxifyed component(e.g. to the programmer of
> > this component).
> >
> > Some weeks ago here was the proposal to replace the current procedure in
> > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> > by something like processAjax() invoked on uiViewRoot. In my opinion
> > this makes sense because there could be more to do than just rendering.
> >
> >
> > Another problem are component specific resources like javascript and
> > style files (*.js and *.css). Currently they are added to the header
> > only if they are needed after rendering the page content. In tomahawk by
> > the ExtensionFilter, in tobago by the PageRenderer after the content was
> > rendered into a buffer. This is not possible if they are rendered by a
> > tabswitching ajax request, because the (html) header is not rendered
> > then. There are two solutions:
> > 1) render always all possible resources into the header (I don' like
> > this)
> > 2) load these resources via clientside scripting (This is what i
> > prefer, but i'm not sure about the best way to do this)
> >
> >
> > Any thougths about the best way to handle these problems?
> >
> > regards,
> >
> > Volker
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
> >
>

Re: Ajax lifecircle integration

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

Volker,

can you contact me at Google talk on this?

We really need to discuss this in detail ;)

regards,

Martin

On 11/5/05, Mike Kienenberger <mk...@gmail.com> wrote:
> Volker,  I don't have any answers for you.
>
> However, by moving the phase listener to after the apply request
> values phase, you're still going to have the same issues with
> validation that you had with InvokeApplication since end-users might
> specify components as immediate=true.
>
> On 11/5/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> > Hi,
> >
> > during working on ajaxifying some tobago components i came over some
> > issues which i like to discuss here.
> >
> > Starting with adding inputSuggestAjax functionality to the tc:in
> > component everything goes well with the current sandbox approach running
> > the AjaxPhaseListener after InvokeApplication.
> >
> > My next step was ajaxifying the server side tab switching of tabgroup.
> > For this in need to add the tabs content values into the request to
> > preserve them in the view. Now the problem of validation and updateModel
> > occurs: If a validation error occurs, then the rest of lifcircle
> > (including AjaxPhaseListener) is skipped and the whole page is rendered
> > as response where only the content of one tab was expected on client side.
> > I decided to move the Listener to after ApplyRequestValues phase. And
> > leave the responsibility for executing other phases (like updateModel
> > and Validation) to the ajaxifyed component(e.g. to the programmer of
> > this component).
> >
> > Some weeks ago here was the proposal to replace the current procedure in
> > AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> > by something like processAjax() invoked on uiViewRoot. In my opinion
> > this makes sense because there could be more to do than just rendering.
> >
> >
> > Another problem are component specific resources like javascript and
> > style files (*.js and *.css). Currently they are added to the header
> > only if they are needed after rendering the page content. In tomahawk by
> > the ExtensionFilter, in tobago by the PageRenderer after the content was
> > rendered into a buffer. This is not possible if they are rendered by a
> > tabswitching ajax request, because the (html) header is not rendered
> > then. There are two solutions:
> > 1) render always all possible resources into the header (I don' like
> >    this)
> > 2) load these resources via clientside scripting (This is what i
> >    prefer, but i'm not sure about the best way to do this)
> >
> >
> > Any thougths about the best way to handle these problems?
> >
> > regards,
> >
> >    Volker
> >
> > --
> > Don't answer to From: address!
> > Mail to this account are droped if not recieved via mailinglist.
> > To contact me direct create the mail address by
> > concatenating my forename to my senders domain.
> >
> >
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: Ajax lifecircle integration

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

Volker,  I don't have any answers for you.

However, by moving the phase listener to after the apply request
values phase, you're still going to have the same issues with
validation that you had with InvokeApplication since end-users might
specify components as immediate=true.

On 11/5/05, Volker Weber <us...@weber-oldenburg.de> wrote:
> Hi,
>
> during working on ajaxifying some tobago components i came over some
> issues which i like to discuss here.
>
> Starting with adding inputSuggestAjax functionality to the tc:in
> component everything goes well with the current sandbox approach running
> the AjaxPhaseListener after InvokeApplication.
>
> My next step was ajaxifying the server side tab switching of tabgroup.
> For this in need to add the tabs content values into the request to
> preserve them in the view. Now the problem of validation and updateModel
> occurs: If a validation error occurs, then the rest of lifcircle
> (including AjaxPhaseListener) is skipped and the whole page is rendered
> as response where only the content of one tab was expected on client side.
> I decided to move the Listener to after ApplyRequestValues phase. And
> leave the responsibility for executing other phases (like updateModel
> and Validation) to the ajaxifyed component(e.g. to the programmer of
> this component).
>
> Some weeks ago here was the proposal to replace the current procedure in
> AjaxPhaseListener ( uiViewRoot.findComponent(<ajaxId>).renderAjax() )
> by something like processAjax() invoked on uiViewRoot. In my opinion
> this makes sense because there could be more to do than just rendering.
>
>
> Another problem are component specific resources like javascript and
> style files (*.js and *.css). Currently they are added to the header
> only if they are needed after rendering the page content. In tomahawk by
> the ExtensionFilter, in tobago by the PageRenderer after the content was
> rendered into a buffer. This is not possible if they are rendered by a
> tabswitching ajax request, because the (html) header is not rendered
> then. There are two solutions:
> 1) render always all possible resources into the header (I don' like
>    this)
> 2) load these resources via clientside scripting (This is what i
>    prefer, but i'm not sure about the best way to do this)
>
>
> Any thougths about the best way to handle these problems?
>
> regards,
>
>    Volker
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
>