I got a comment from a Tom Baeyens (a colleague here at Red Hat who was integrating UEL into jBPM) that he was surprised that he had to do so much manual setup of EL (for example adding all the "built in" EL resolvers such as MapELResolver, having to manually create an expression factory).
On 19 Feb 2010, at 19:37, Kin-man Chung 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!
>
> 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
>
> ---------------------------------------------------------------------
> 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
>