Hi Pete!
As a gut feeling, the EL namespacing looks a bit ugly.
Need to get my head around it after being back from vacation (~Saturday).
A main feature of namespaces is that they don't need to be repeated if it doesn't
change subsequently. Thus if I e.g. have a ui:fragment which all operates on beans of one
package, I like to notate the namespace just once. Does the current proposal reflect
this?
LieGrue,
strub
--- On Tue, 8/23/11, Pete Muir <pmuir(a)redhat.com> wrote:
From: Pete Muir <pmuir(a)redhat.com>
Subject: [cdi-dev] EL namespaces
To: "CDI-Dev" <cdi-dev(a)lists.jboss.org>
Date: Tuesday, August 23, 2011, 3:27 PM
Hi all,
On the JSR-341 (EL.next) we've been discussing making bean
namespacing a first class feature.
Currently the proposal on the table from JSR-341 is that
the built in conversation bean would be referenced by
#{N(javax.enterprise.context).conversation}. This is
obviously a deviation from the syntax that CDI 1.0 has used
(#{javax.enterprise.context.conversation}) but does remove
the ambiguity between property/method access and namespacing
that is inherent in the CDI 1.0 option.
I would propose that the CDI 1.1 spec is updated to
recommend this approach, and that the old approach is
deprecated for CDI 1.1 (but still required to work). We can
then address in CDI 1.1.next whether we want to remove the
1.0 approach, or keep it for backwards compatibility.
Below is the thread on which we discussed this, including
some ideas on how to implement the old approach on top of
the new EL namespace support.
Any concerns?
Pete
Begin forwarded message:
> From: Kin-man Chung <kinman.chung(a)oracle.com>
> Date: 12 August 2011 19:24:16 GMT+01:00
> To: jsr341-experts(a)el-spec.java.net
> Subject: [jsr341-experts] Re: Bean names with
namespace
> Reply-To: jsr341-experts(a)el-spec.java.net
>
> On 08/12/11 10:29, Pete Muir wrote:
>> Sorry for the late reply.
>>
>> On 9 Aug 2011, at 21:25, Kin-man
Chung wrote:
>>
>>
>>> On 08/09/11 12:03, Pete Muir wrote:
>>>
>>>> On 9 Aug 2011, at 18:02, Kin-man Chung
wrote:
>>>>
>>>>
>>>>
>>>>> I recall that it is a CDI requirement
that bean names can have namespaces, such as
"org.goofy.configs". Pete, is this still the case?
>>>>>
>>>>>
>>>> Yes. This is in the CDI spec, so can't be
removed right away, we need to support this for at least the
next revision.
>>>>
>>>>
>>>>
>>> I am curious about how it got in the CDI spec
in the first place? It is just a little strange that
CDI can write into its spec about some functionalities in
another spec that is currently not supported, to say the
least.
>>>
>> Sure. CDI doesn't require UEL to support
namespaced beans generally, however it does require that:
>>
>> * CDI beans can have names which include
namespaces as above
>> * CDI beans with names are resolvable by UEL
>>
>> So I don't *think* CDI is specifying a UEL
feature, but simply specifying it's own features and
integrations.
>>
>>
> Thanks for clarifying this.
>
> Still, if UEL was consulted before this was put in the
CDI spec, it would have been apparent that it's not a good
idea to introduce such ambiguities, and that another syntax
would have been used. Of course I understand that UEL
has not been active for a long time, to say the least, and
CDI probably just want to move forward. :-)
>
>>>
>>>>> Are there any other things that
EL needs to do, other than the ability to parse and
evaluates it?
>>>>>
>>>>>
>>>> No.
>>>>
>>>>
>>>>
>>>>> Since names that contains a "."
creates ambiguities are parse time, we'll need to resolve
it. I propose that we introduce another syntax
notation for it, like what we did for static fields.
For instance, we can write
>>>>>
>>>>>
#{N(org.goofy.configs).memSize}.
>>>>>
>>>>> to denote the bean org.goofy.configs
with the property memSize. What do you think?
>>>>>
>>>>>
>>>> This wouldn't work for CDI due to
backwards compatibility.
>>>>
>>>>
>>>>
>>> What backwards compatibility? It is not
working currently! Did you really got it to work with
EL 2.2? How?
>>>
>> Yes it works with UEL 2.2. As we know at
deployment time all the bean names, including namespaces, we
can create synthetic objects for each node in the namespace
hierarchy needed. For example we would create an "org"
object, with a "goofy" child object (and perhaps a "jboss"
child object were org.jboss.plmuir.Foo a bean we have as
well). When "org" is passed to our namespace EL resolver, we
return this org synthetic object. This is then passed in as
the base when "goofy" is the property to resolve, and we
return the Goofy object (and so on). If we don't have a
namespace object, of course we return null.
>>
>> Then, in our bean resolver, if the base is a
namespace object, we can cast to it, and simply call a
method on it to retrieve the fully-qualified namespace,
concatenate the current property name, and do a bean
lookup.
>>
>>
>>> What I like about the N() notation is that it
is easy on the parser as well as on the user. It
provides a visual indication about what the expression
does. In general, it is just not a good language
design to contain ambiguities that cannot be easily
resolved.
>>>
>> Understood.
>>
>>
>>>
>>>> Instead (or as well?), could we offer a
registerNamespace() method (similar to how we are handling
imports)? Then EL will have a static list of namespaces that
an (optional?) namespace resolver could resolve against
before other resolvers are used. CDI knows namespaces at
startup so could register all it needs.
>>>>
>>>> WDYT?
>>>>
>>> If we have to support it without any syntax
aid, we'll need to have something like
registerNamespace(). I am not sure how and when the
information can be best used. Ideally, we'd like to be
able to recognize the namespaces early, at parse time, so
that we don't need to change how it works at evaluation, so
ELResolvers may not be the right solution. Even at the
parse time, it'll require either a deep look-ahead or
backtracking. Also, a simple typo can produce errors
that are hard to track down.
>>>
>>> Can CDI deprecate the current namespace
support in favor of the N() notation?
>>>
>> Yes, I can make it "optional" in 1.1 I guess,
introduce the N() notation and then we can remove it in CDI
1.1+1.
>>
>>
> Can you make sure that CDI EGs are OK with this?
Thanks.
>
>> I'm not wedded to the syntax, just looking for the
best solution all around.
>>
>>
> I also don't like having to introduce another reserved
word. But since we have already introduced T(), a N()
is not too bad. Of course if you have other ideas,
we'll be glad to consider them.
>
>>> Can CDI implementation provides a tools
to turn #{org.goofy.configs.memSize} into
#{N(org.goofy.configs).memSize}?
>>>
>> I guess, because we know the namespaces up front,
we can simply check if org.goofy.configs is a registered
namespace, and if it is, rewrite the EL expression. Does
that sound reasonable?
> Yes, it is. Of course this is just a suggestion
for a way to implement namespace in CDI, taking advantage of
the new N() syntax in EL, so that the complicated hack with
ELResolvers would not necessary.
>
> Thanks. I am really glad that we've arrived at a
solution acceptable to all of us! :-)
>
> Kin-man
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev