jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Please Review: JSF 2.3 EDR draft

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Fri, 9 Oct 2015 18:04:10 +0200

Hi,

On Fri, Oct 9, 2015 at 4:44 PM, Kito Mann <kito.mann_at_virtua.com> wrote:

> * We should consider renaming some of the annotations so it's clear which
> ones refer to a Map backed by a scope:
>
> - FlowScopeMap
> - ViewScopeMap
> - RequestScopeMap
> - SessionScopeMap
> - FlashScopeMap (was Flash in the Javadocs?)

This was indeed something I was looking at, at least to go through the
entire list. The annotation names were now chosen based on the API
calls (mostly, I made one mistake that still had to be corrected).

E.g.

Given

API: FacesContext.getCurrentInstance().getViewRoot().getViewMap()
Producer/Bean<T>: ViewMapProducer
Annotation: ViewMap
Existing EL name: viewScope

API: FacesContext.getCurrentInstance().getExternalContext().getSessionMap()
Producer/Bean<T>: SessionMapProducer
Annotation: SessionMap
Existing EL name: sessionScope

API: FacesContext.getCurrentInstance().getExternalContext().getRequestCookieMap()
Producer/Bean<T>: RequestCookieMapProducer
Annotation: RequestCookieMap
Existing EL name: cookie

At the moment many of the existing EL names are not entirely
consistent with their backing API names.

If we go for say ViewScopeMap, then this is basically a third name; a
combination between the EL name and the API name. More confusing or
less confusing? I don't know.



> - Is there a way we can avoid the requirement to place the
> <f:validateWholeBean> tag after everything else? That's just asking for
> trouble.

I still have to look at how f:validateWholeBean was exactly
implemented, but as I mentioned in the reply to Leonardo, OmniFaces
uses a tag handler and listens for events. *Maybe* that approach is
possible here too.



> - Is there a way to specify a short name (i.e. not the fully qualified
> class name) for validation groups?
>
> * CDI Integration
>
> - We should also support injecting Application

Another issue I wanted to bring forward to the EG ;)

We now with 1 exception followed the list of existing implicit EL
variables. Which other artifacts should be injectable?



> * UIData and <ui:repeat> supports Map and Iterable
>
> - (!) We should update the prose to specifically mention Iterable for the
> list of types supported by UIData and <ui:repeat>.

ui:repeat is unfortunately not mentioned in the spec text now at all.

It was indeed the intend to put the complete list in the spec text
(see associated issues).

Kind regards,
Arjan tijms