[cdi-dev] EL namespaces

Thu Aug 25 05:12:31 EDT 2011

Yes, I can see why it might look ugly. I suggest you relay any comments on this to Kin-man and he can pass them onto the UEL EG.

There is also no support currently for importing a namespace into an EL context, and again, suggest you raise this with Kin-man. OTOH there is support being added for aliasing beans (related but not the same).

On 25 Aug 2011, at 09:13, Mark Struberg wrote:

> 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 at redhat.com> wrote:
> 
>> From: Pete Muir <pmuir at redhat.com>
>> Subject: [cdi-dev] EL namespaces
>> To: "CDI-Dev" <cdi-dev at 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 at oracle.com>
>>> Date: 12 August 2011 19:24:16 GMT+01:00
>>> To: jsr341-experts at el-spec.java.net
>>> Subject: [jsr341-experts] Re: Bean names with
>> namespace
>>> Reply-To: jsr341-experts at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 