[cdi-dev] EL namespaces

Thu Aug 25 04:13:59 EDT 2011

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
> 