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!
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.
I already have ExpressionFactory. Can we combine it with ELContext,
to make things simpler?
I think this would probably be enough to start the discussion. :-)
-Kin-man