>>>>> On Thu, 16 Feb 2012 23:30:31 +0100, Martin Marinschek <mmarinschek_at_apache.org> said:
MM> Why would this make a difference? You could sell to me that you
MM> cannot use @Named due to technological restrictions - but you cannot
MM> sell to me that you cannot use it because UIComponents are not
MM> Pojos.
The initial spirit of @FacesComponent, and all the other config
annotations, was to get rid of XML.
MM> I rather think that UIComponents should be much more like Pojos in
MM> the end ;)
MM> In any case, in a CDI container, every class is a bean, as long as
MM> there is a META-INF/beans.xml in the same "package" (e.g. jar file).
MM> So also UIComponents will end up being beans if this file is there.
I think I see where you're going with this and it's a desirable goal,
but I think a POJO based view framework is outside the scope of JSF 2.2,
and certainly not what was requested in [594-FacesComponentTagHandler].
>>>>> On Fri, 17 Feb 2012 09:13:16 -0500, Kito Mann <kito.mann_at_virtua.com> said:
KM> I feel like @Named has a different purpose, though -- exposing the
KM> component to CDI. Wouldn't using it here be a little confusing?
I tend to agree. Perhaps we can think along these lines when inventing
a new view framework on top of JSF.
KM> How about using a different annotation instead, like @FacesTag? This avoids
KM> the need to always set an attribute to true for the @FacesComponent
KM> annotation, and it would be easy to support an a default attribute that can
KM> provide an alternate name.
I like that idea, but I'd need some more support before I invest the
time in the code. Anyone?
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/