(b) The asynchronous call is completely independent of theThe 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.
originating view, and should be a completely separate request.
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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* < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]>> 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* < [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> > > > > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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 <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED] >
> > > > > <mailto: [EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]>>> 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.
>
