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]> 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]>> 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]>> 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.
>

Reply via email to