myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: Ajax lifecircle integration
Date Thu, 10 Nov 2005 20:44:23 GMT
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
> > <mailto:martin.marinschek@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
> >     <mailto:mkienenb@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
> >     <mailto:mkienenb@gmail.com>
> >     > > > <mailto: 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>
> >     > > >     <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.
>

Mime
View raw message