Hi Ernst, On Thu, Mar 27, 2008 at 10:12 PM, Ernst Fastl <[EMAIL PROTECTED]> wrote: > Thanks for the info - I didn't know that. > > Still - I'd just like to point out, that the initial IDEA of the > PPRPanelGroup was > to have a normal JSF-Lifecycle just with different rendering (partial > updates instead > of full page refreshes) so the PhaseListener before render response > appeared to be > the logical choice. > > That doesn't mean that I would be against any other solution. At which > classes would > I need to look in order to get an idea of how the custom lifecycle > works and which > benefits we would have if we switch?
in Tobago, there is this package (of its core): org.apache.myfaces.tobago.lifecycle that has all the interesting stuff (+ some utils from "outside" this package) we do similar. Have a factory + an lifecycle that looks for a "list of ids" for the ajax components and calls the processXzy() lifecycle methods only on these guys. But... some issues (at least in JSF 1.2) can come along here. See my JSF spec bug: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=331 -Matthias > > regards > > Ernst > > > > On Thu, Mar 27, 2008 at 10:06 PM, Volker Weber <[EMAIL PROTECTED]> wrote: > > Hi, > > > > custom lifecycles are possible in jsf1.1, tobago has a custom > > lifecycle which integrates the ajax (ppr) into the normal jsf > > lifcycle. in case of ajax the process* methods are only run on the > > partially requested components. > > > > > > Regards, > > Volker > > > > > > > > 2008/3/27, Ernst Fastl <[EMAIL PROTECTED]>: > > > > > > > This seems to be addressing the more general JSF Problem "immediate is > > > not enough" > > > which the subForm tries to solve. I personally would dream of instead > > > of just required=true|false > > > requiredFor="buttonId1,buttonId2,..." but that might just be an IDEA > > > for JSF 2.0. > > > > > > The reason PPR uses a PhaseListener is that it was started and should > > > still work in JSF 1.1. > > > As far as I remember there were no custom lifecycles in 1.1. > > > > > > The PhaseListener currently only kicks in before Render Response which > > > would be to late > > > for a feature like that. > > > > > > I think the approach with updateComponentIds="" could be implemented > in the > > > PhaseListener as well if it also checks > > > after processDecodes for some sort of "partialUpdate" parameter and > > > then manually > > > invokes validation and conversion on the targeted components - and > afterwards > > > just does, what it now does before render response > > > > > > just my 2 cents > > > > > > > > > Ernst > > > > > > > > > On Thu, Mar 27, 2008 at 8:08 PM, Thomas Spiegl <[EMAIL PROTECTED]> > wrote: > > > > ok, now I got it - nice approach +1 > > > > > > > > > > > > > > > > > > > On Thu, Mar 27, 2008 at 2:54 PM, Mari Ivankovits <[EMAIL PROTECTED]> > wrote: > > > > > Hi! > > > > > > > > > > > The pprSubmit is something like a generic autoSubmit feature for > > > > > > command components (see also autoSubmit attribute in trinidad). > > > > > > > > > > > ? pprSubmit does nothing else than rendering the javascript to > hook on > > > > > the new components too, no? > > > > > I do not understand what you mean with autoSubmit here. > > > > > > > > > > > > > > > > Adding this feature to pprSubmit would somehow break the > existing ppr > > > > > > behavior, where the triggered components register themselves > for > > > > > > updates. > > > > > > > > > > > I do not change the existing ppr behavior, just how the data > sent by it > > > > > will be processed on the server. If this will break the ppr > philosophy > > > > > then I think the ppr is broken at all, isn't it? > > > > > > > > > > Just to be sure everyone understand what I would like to have. > > > > > The interesting part of this view is: > > > > > * a single form > > > > > * a required customer name > > > > > * a country/zip pair which needs to be available in the model > during ppr > > > > > * a city which will be computed out of the country/zip data > during ppr > > > > > > > > > > The problem is, that due to the required customer the ppr will > not work > > > > > due to the validation error which will happen. > > > > > > > > > > <h:form> > > > > > <s:pprPanelGroup partialTrigger="lookupCity"> > > > > > <t:panelGrid columns="2"> > > > > > <h:outputText value="Customer Name" /> > > > > > <h:inputText id="name" value="#{bean.name}" > required="true" /> > > > > > > > > > > <h:outputText value="Country" /> > > > > > <h:selectOneMenu id="country" value="#{bean.country}" > /> > > > > > > > > > > <h:outputText value="Zip" /> > > > > > <h:inputText id="zip" value="#{bean.zip}" > required="true"> > > > > > <s:submitOnEvent event="change" for="lookupCity" > /> > > > > > </h:inputText> > > > > > > > > > > <h:outputText value="City" /> > > > > > <h:panelGroup> > > > > > <h:outputText id="cityAuto" > value="#{bean.cityAuto}" > > > > > renderer="#{bean.cityAuto}"/> > > > > > <h:commandButton action="#{bean.overrideCity}" > > > > > renderer="#{bean.cityAuto}"/> > > > > > <h:inputText id="cityMan" value="#{bean.cityMan}" > > > > > renderer="#{!bean.cityAuto}" required="true" /> > > > > > <h:commandButton > action="#{bean.resetCityToAutomatic}" > > > > > renderer="#{!bean.cityAuto}"/> > > > > > </h:panelGroup> > > > > > > > > > > </t:panelGrid> > > > > > > > > > > </s:pprPanelGroup> > > > > > > > > > > <h:commandButton id="lookupCity" action="#{bean.lookupCity}" > style="hidden"> > > > > > <s:pprSubmit processComponentIds="country,zip" /> > > > > > </h:commandButton> > > > > > > > > > > <h:commandButton action="#{bean.save}" /> > > > > > </h:form> > > > > > > > > > > The complicated thing is, that the pprSubmit enhancement would > require a > > > > > custom LifeCycle for PPR requests (why is it a PhaseListener by > now?) > > > > > > > > > > > > > > > Another possibility to fix that would be to enhance subForm to > nicely > > > > > work in a nested mode so that you can have a subForm with > multiple > > > > > subForms within and a logical name (new attribute) to group the > subForms > > > > > together. > > > > > Then ppr as it is today might work then, the resulting view > wouldn't > > > > > look nice though. > > > > > > > > > > Or, using RichFaces with its ajax implementation which might > allow this > > > > > already ... adding this library for just one function seems > weird to me > > > > > though :-( > > > > > > > > > > Ciao, > > > > > Mario > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > http://www.irian.at > > > > > > > > Your JSF powerhouse - > > > > JSF Consulting, Development and > > > > Courses in English and German > > > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > > -- > > inexso - information exchange solutions GmbH > > Bismarckstraße 13 | 26122 Oldenburg > > Tel.: +49 441 4082 356 | > > FAX: +49 441 4082 355 | www.inexso.de > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
