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
