On 12-10-17 08:24 AM, Christian Kaltepoth wrote:
+1 for @BeforePhase and @AfterPhase.
Agreed, this is tighter than the pair of annotations required in Seam Faces.
I like that this forces the user to specify both the concrete phase and the
time (before vs after).
+0.8 for @BeforeFacesRequest, @AfterFacesRequest
+1 !!
and @JsfPhaseListener
can we not build on the @ListenerFor annotation in JSF [1]?
@ListenerFor(phaseEventClass=...)
or, if we need a unique name, perhaps:
@ListenerForPhase(phaseEventClass=...)
I like the concept, but I suggest that we use "Jsf" or "Faces" consistently
+1 for being consistent between JSF/Faces in general.
Brian
in the annotation names. So if we use @BeforeFacesRequest, we should also
use @FacesPhaseListener. This would also apply to the enum JsfPhaseId.
Perhaps we could just use "Phase" here?
Christian
2012/10/17 Pete Muir <[email protected]>
+0 from me, I would be happy with either + don't really use JSF anymore ;-)
On 17 Oct 2012, at 10:27, Mark Struberg wrote:
+1
looks really good!
LieGrue,
strub
----- Original Message -----
From: Gerhard Petracek <[email protected]>
To: deltaspike <[email protected]>
Cc:
Sent: Wednesday, October 17, 2012 11:14 AM
Subject: Re: [DISCUSS] features related to the jsf lifecycle
+1 for:
@BeforePhase / @AfterPhase
@BeforeFacesRequest / @AfterFacesRequest
@JsfPhaseListener
regards,
gerhard
2012/10/17 Gerhard Petracek <[email protected]>
hi @ all,
the support of cdi-observers for jsf phase-events in codi and
seam-faces
is very similar.
a central difference is that codi uses only one additional annotation
per
observer.
initially it was a workaround for a portability issue. however, you
only
have to remember one annotation (per observer) and you get the rest via
std. auto-complete.
example:
protected void observePreRenderView(@Observes
@BeforePhase(RENDER_RESPONSE) PhaseEvent phaseEvent) {
//...
}
codi even supports to filter it for views - e.g.:
@View(DemoPage.class)
public void observePostInvokeApplication(@Observes
@AfterPhase(JsfPhaseId.INVOKE_APPLICATION) PhaseEvent event) {
//...
}
but we have to postpone that part for now until we have an agreement
concerning type-safe view-config and navigation.
(@View is also used for other features in codi.)
furthermore, we could add @BeforeFacesRequest and @AfterFacesRequest.
technically we could merge them with the annotations for phase-events,
but
i wouldn't do it (because it's a slightly different topic and might
confuse
users).
moreover, we could add @JsfPhaseListener which allows to add std. jsf
phase-listeners without xml config and enables injection support for
them.
in codi we really register those listeners -> per default you don't
have
an overhead. however, we needed some workarounds for mojarra.
-> as an alternative we could register one ds-phase-listener per
default
which delegates to beans with @JsfPhaseListener.
since we don't support jsf 1.2, we can skip
JsfLifecyclePhaseInformation
(jsf 2.0+ provides FacesContext#getCurrentPhaseId).
regards,
gerhard
