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?
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
>
