+1 for @BeforePhase and @AfterPhase. I like that this forces the user to specify both the concrete phase and the time (before vs after).
+0.8 for @BeforeFacesRequest, @AfterFacesRequest and @JsfPhaseListener I like the concept, but I suggest that we use "Jsf" or "Faces" consistently 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 > >>> > >> > > -- Christian Kaltepoth Blog: http://chkal.blogspot.com/ Twitter: http://twitter.com/chkal
