On 03/24/10 13:23, Ed Burns wrote:
>>>>>> On Wed, 17 Mar 2010 16:59:31 -0600, Jason Porter<lightguard.jp_at_gmail.com> said:
>
> JP> Would be it too much to assume that the class would already be a bean
> JP> that we could resolve? If we had that limitation then we avoid the
> JP> package problem.
>
> Seems reasonable to me.
>
> KC> Well, the point of using a static method is not requiring an bean
> KC> instance. We should not have such restriction.
>
> We don't have to instantiate it to know it has a static method. In JSF,
> the ManagedBeanELResolver looks at the "base", checks if it matches a
> declared managed bean name, and then, and only then, instantiates it.
> We could have a new ELResolver in the chain, before the ManagedBean
> ELResolver, that checks "base" to see if it matches a declared managed
> bean, then looks to see if it has a static method whose name equals
> "property".
>
> The problem here is that the very concept of ManagedBeans is outside of
> EL, so we'd have to figure that out somehow.
>
Right. El needs to be told about the beans that have been registered.
Previously, I have proposed a BeanLookup (I know, Christoph hates the
name :-) ) interface to allow EL engine to obtain an instance of the
named object, and I think we can also use it to find out about the type
of the beans, even if it has not been instantiated.
interface BeanLookjp {
Object getBean(String name); // return an instance of the bean
Class<?> getBeanType(String name);// return the bean class
}
The application or the bean container can register an instance of this
interface with the EL engine. With this, expressions such as
#{beanRegisteredButNotInstantiated.myFunc()}
can then be used for calling static functions.
-Kin-man
> Ed
>