+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 <gerhard.petra...@gmail.com>
>> To: deltaspike <deltaspike-dev@incubator.apache.org>
>> 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 <gerhard.petra...@gmail.com>
>>
>>> 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
>>>
>>
