Hi!
Sorry for the lengthy mail ... Solving this problem just made me crazy
so easy problem, and so complicate if not impossible solution with JSF.
Everything I toucht in the last couple of days had some
side-effect/influence on something else.
My simple country/zip immediate show city ppr
Hi!
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
I am investigating some time into that.
In fact, the thing missing now is invokeOnComponent, didn't we have
something like this in MyFaces
Hi,
On Sat, Mar 29, 2008 at 3:16 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
I am investigating some time into that.
In fact, the
Hi!
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
I am investigating some time into that.
Ok, I've committed something which did the trick. I've not yet fully
replace the PhaseListener
Hi!
I have the need to do a partial model update for given components on ppr
submit. (subform won't work here)
I have a form with a couple of input fields, lets say FIELD_A, FIELD_B,
FIELD_C, FIELD_D - all in one form.
FIELD_A is required
now, after something has been entered in FIELD_B,
Hi Mario,
i think this usecase is already covered by the component. Have a look
at the current nightly build page
http://example.irian.at/example-sandbox-20080327/pprPanelGroupOnChange.jsf
Especially the input component in combination with the outputText element.
You may have to play with
The pprSubmit is something like a generic autoSubmit feature for
command components (see also autoSubmit attribute in trinidad).
Adding this feature to pprSubmit would somehow break the existing ppr
behavior, where the triggered components register themselves for
updates.
Thomas
On Thu, Mar 27,
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.
ok, now I got it - nice approach +1
On Thu, Mar 27, 2008 at 2:54 PM, Mario 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
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
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]:
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
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
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
14 matches
Mail list logo
