Hi,
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.
yup. You mimic the invokeOnComponent() :-)
I love that!!
Internally we have an optimized lifecycle, where the callbacks call
the lifecycle methods (processXyz()) are called only on the "ajax-ish"
components.
I am looking forward to add that to Trinidad 1.2.x as well
-M
>
>
> 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
