deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Leathem <bleat...@gmail.com>
Subject Re: [DISCUSS] features related to the jsf lifecycle
Date Wed, 17 Oct 2012 18:17:46 GMT
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 <pmuir@redhat.com>
>
>> +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.petracek@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.petracek@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
>>>>>
>>
>


Mime
View raw message