Hi
I forgot to do some comments about section 5.9 CDI Integration.
If I understand well, the idea is if CDI is active, the objects
mentioned on the list (application, cc, component,
facesContext ...) will be resolved using a CDI Producer and
then the context will get them through CDI EL Resolver.
That's ok, but it raises some questions:
1. Is the code still on JSF side? I say that, because flowScope
and viewScope are mentioned there, but I'm afraid there are
some necessary hacks there that makes impossible (with
the current spec) to move these scopes into CDI codebase
(if that's the intention, I suppose it is not, I just want to be sure).
2. How are the objects created? I saw that you can use
@Inject over javax.faces.component.UIViewRoot, but if that
so, how will a session scope bean with an UIViewRoot be
passivated without serialize/save the UIViewRoot? I say
that becausein the past what we did to allow converters
and validatorsto use @Inject in MyFaces was create some
wrappers implementing PartialStateHolder and
FacesWrapper. I'm sure CDI 1.0 doesn't help with the
required proxy/wrapper, but ignore if the new CDI 2.0 API
has something new that helps in this case.
In my understanding, only if CDI creates/manage the object,
the passivation will be done correctly.
regards,
Leonardo Uribe
2015-10-09 11:04 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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
>