On Fri, Feb 19, 2010 at 12:37, Kin-man Chung <Kin-Man.Chung_at_sun.com> wrote:
> To decide what we should discuss first, I think we should put down in
> a page the issues and requests, and pick the topics that are more
> important or basic. It can be more effective with wikis pages. For
> now, let me just pick a topic. If you have other topic that need to
> be covered first, let's have them too!
Not first, but at least so it's on the board (I think we pretty much
all agree on these two) better performance and Java 5 features such as
Enum resolution.
> Let's start our discussion on making EL easier to use, especially
> when used outside of JSP or JSF. Let me just copy Dan;s writeup on
> this here. I added the item numbers for the ease of reference.
>
> Item 1: Bootstrapping the ELContext (P1)
>
> Current the ELContext is created in the UI layer, either by JavaServer Faces
> or JSP. However, EL is an essential part of the Java EE programming model.
> It would make a lot more sense if the ELContext would be created at the
> start of the request so that components such as filters, custom servlets and
> third-party frameworks could access the EL. Currently, it's necessary to
> manually construct an EL context if an expression needs to be resolved
> outside of JSF or JSP.
>
> What we are looking for is something similar to the bootstrap that was
> introduced for Bean Validation. Like Bean Validation, EL transcends the
> layers of the programming model and should therefore be universally
> accessible.
>
> Item 2: Simplifying the expression evaluator API (P1)
>
> It's way too complicated to resolve an EL expression. If you think about it,
> the task is quite simple. Take an expression string and get a result. We
> need to make the API as simple as the task.
>
> Part of the problem with the Unified EL is that just trying to figure out
> what you need to actually resolve an expression is a nightmare. It breaks
> down into three parts:
>
> * ELContext - Simply put, To evaluate an Expression, an ELContext must be
> provided. A real bitch.
> * ExpressionFactory - Needed to create a ValueExpression or
> MethodExpression from a string
> * ELResolver - The thing that actually parses the expression and
> deferences its parts; each job is handled by a different resolver (one being
> to find CDI beans by name) and those resolvers are wrapped in a resolver
> which is a chain of resolver
>
> What isn't provided is a simple API to just take an expression and get a
> result from it.
>
>
> I think these two items are related, so let's talk about item 1 first.
> There are actually two parts to this item:
>
> 1.1. In a web container, how can one obtain an instance of ELContext
> when the request is first created?
>
> 1.2. In a non-web context, how to bootstrap the ELContext?
>
> Let tackle 1.2 first, since it may influence how 1.1 is solved.
>
> We can do something similar to bootstrap API in Bean Validation, but it
> still remains a fact that components of a ELContext, such as ELResolver
> need to be specified somehow. We can, for instance, have a default
> ELResolver that includes the common ELResolvers, such a BeanELResolver
> etc, but user must still need to be able to use a map to resolve his/her
> bean. For instance, in the expression #{foo.bar.baz}, s/he can rely on
> the default ELResolver to resolve the operator ".", but s/he must
> still tell us how foo should be resolved.
Bean registration with the resolver is something I was thinking about
the other day because Ed had mentioned how nice it would be to use EL
everywhere (+1 from me as well). Would we want resolution for all
classes, or only managed classes? If it were all classes then what was
done with CDI and the default name would seem to work (unless you had
classes with the same name but in a different package, then we run
into complications). Perhaps a discussion on what classes are
available for resolution is needed. If it's only managed classes then
we're kind of back to square one unless there's a way to obtain all
the managed classes from the various environments.
> I already have ExpressionFactory. Can we combine it with ELContext,
> to make things simpler?
I'm all for simplifying the API as much as possible. One of the
things we could do to help maintain backwards compatibility and still
make it simple for the use case outside of the view layer is to
provide a shortcut entry point. The shortcut would have to use a
context that's already been started and have a valid ELResolver but
something as simple as ExpressionFactory.parse(String) or possibly
ExpressionFactory.parse(String, returnType) would probably go a long
way into making EL easier to use outside of a managed context.
> I think this would probably be enough to start the discussion. :-)
>
> -Kin-man
>
--
Jason Porter