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