el-next@uel.java.net

Re: Making EL easier to use

From: Kin-man Chung <Kin-Man.Chung_at_Sun.COM>
Date: Tue, 09 Mar 2010 16:05:34 -0800

On 03/04/10 09:02, Jason Porter wrote:
> On Thu, Mar 4, 2010 at 09:44, Lincoln Baxter, III
> <lincolnbaxter_at_gmail.com> wrote:
>> I agree with Martin.
>>
>> One of the greatest strong-points of JavaEE components is their re-use
>> outside of the web-containers. CDI / Dependency Injection, for example,
>> already supports the SE environment (Weld does.) I'd like to see EL
>> available anywhere that contexts are available. The pairing of these two
>> tools is very powerful, both in the web-tier, and in the SE application
>> world. All that I need to do to see this value is to transpose Web
>> Applications into the world of Desktop Applications.
>>
>> We've become so accustomed to these features, and I'd hate to go without it
>> in an application of similar complexity, just because it's on the Desktop,
>> not on the Web :)
>>
>> --Lincoln
>>
>> On Thu, Mar 4, 2010 at 1:34 AM, Martin Marinschek
>> <martin.marinschek_at_gmail.com> wrote:
>>> Hi Kin-Man
>>>
>>>> Should we then say EL will assume a bean-container and not worry about
>>>> SE environment? I know I said that our goal is to make EL easier to use
>>>> "inside and outside of Java EE", and what do we meant by "outside of
>>>> Java EE" then?
>>> Java EE means (at least for me) application server - bean containers
>>> are available and running on Java SE environments like a pure servlet
>>> container as well.
>>>
>>> best regards,
>>>
>>> Martin
>>>
>>>>> best regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>>
>
> I agree with the above posts as well. There are bean containers that
> live in the SE world that really could take advantage of EL. CDI (I
> think all of the three actually support an SE environment), Spring,
> Guice, etc all live in SE. I know it's a huge stretch to say Swing
> could use it, but it could be possible some day, and could be a huge
> win IMO. Being able to create an ELContext and the rest of the gang
> outside of Java EE should allow us to expose EL in the SE world.
>

OK, we should then say that our goal is to make EL easier to use in a
bean container. It doesn't matter whether the container is a JavaEE, a
web container, or just a SE application with managed beans.

Currently ELContext is created in JSP or JSF container. We'll need to
put this, and other EL objects in an EL container for our use. Let
me think about this more and we can discuss in another thread.

> About the extra classes, I'm fine with it as long as we have an easy
> syntax that works for the majority of the cases, I'd like to either 1)
> cut down the boiler plate bloat or at least 2) keep it same. We've
> definitely seen the shift in the Java EE from boiler plate to
> annotations and the like. I'm not suggesting annotations for EL, but
> reducing the boiler plate needed to setup would be a plus.
>
I think the use of an EL container will address this.