On 09.04.2010 21:00, Kin-man Chung wrote:
> On 04/09/10 11:33, Christoph Beck wrote:
>> On 09.04.2010 20:11, Kin-man Chung wrote:
>>> On 04/09/10 06:47, Pete Muir wrote:
>>>> The CDI spec calls for namespaced bean names (see section 2.5). It
>>>> says
>>>>
>>>> "A bean may have a bean EL name. A bean with an EL name may be
>>>> referred to by its name in Unified EL expressions. A valid bean EL
>>>> name is a period-separated list of valid EL identifiers.
>>>>
>>>> The following strings are valid EL names:
>>>>
>>>> * org.mydomain.myapp.settings
>>>> * orderManager"
>>>>
>>> Just need to make sure I understand, and showing my ignorance about
>>> CDI:
>>>
>>> The expression #{org.mydomain.myapp.settings.standard} actually
>>> means getting the property "standard" from the bean
>>>
>>> org.mydomain.myapp.settings, right? How can this work with the
>>> current EL? Wouldn't the expression be parsed as getting the bean
>>> "org" and then get its property "mydomain", and then its property
>>> "myapp" etc?
>>>
>>> Interestingly, the parsing problem we have here is the same as that
>>> in the static methods. So maybe we can find a mechanism that works
>>> in both cases.
>>>
>>
>> Wouldn't this be done simply with an ELResolver placed prior to the
>> BeanELResolver in the chain of resolvers?
>>
> No. The problem is that of parsing, and not name resolution. i.e,
> we'll have decide first that "org.mydomain.myapp.settings" is really
> an EL identifier and not identifiers separated by ".'s.
>
Yes, OK. If the bean names are known at parse time, this could be done
by e.g. post-processing the parse tree and merging the nodes for path
org/mydomain/myapp/settings into a single identifier node. In the end,
this looks like if we could reuse the variable mechanism for this,
extending it to allow dot-separated identifiers?
> Kin-man
>>>
>>>> I would like that we consider if this is something UEL can
>>>> (should?) support natively. This could be part of BeanLookup
>>>> contract that Kin-man proposed. We've already discussed whether it
>>>> is possible to parse out the package name for static method calls,
>>>> so I hope we can apply the result of that discussion here...
>>>> WDYT?
>>>>
>>> Agreed. Let me think about this/
>>>
>>> -Kin-man
>>>> Pete
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>>>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
>> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>