commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Rasmussen <>
Subject Re: [Chain] adding EL support
Date Fri, 10 Jun 2005 17:52:35 GMT
On 6/10/05, Joe Germuska <> wrote:
> At 11:23 AM -0500 6/10/05, Michael Rasmussen wrote:
> >I am working with a framework similar to chain at my day job.  One of
> >the nice features of the framework I work with is that all of the core
> >'commands' support EL Evaluation when they take in values.  This is
> >something I would be interested in submitting a patch for if there is
> >a hint of interest.
> There's more than a hint; I've been using JEXL extensively with chain
> in my day job, and have made suggestions to the list before that it
> could be useful.  However, I am sensitive to the general sense that
> dependencies should be added lightly.
> Specifically, situations where you use the actual Chain context
> itself as the Expression evaluation context (or at least its basis)
> make a lot of cool things possible.
> I'm about to leave for vacation for a week, but I think this is a
> good general idea and would only want to see if other people have
> strong feelings about the dependencies or the packaging.  (One
> suggestion was that chain could have a secondary distribution
> artifact, something like ant-optional.  

  The question I have if you make an optional library is how do you
integrate the EL support in to the commands?  Would you do it within
digester?  My initial thought was to take the core commands and add it
command by command.  The optional library approach would reqire these
commands to live outside the core as well.  Which may not be a bad
thing either as currently the core project contains code specific to
struts, jsf, and others.  But that is a whole other can of worms.

>Obviously that solves the dependency question neatly, but it adds
considerable management
> overhead, and I simply haven't had time lately to set things up that
> way.)

If I can get some general direction on which way makes sense to go, I
canat least take a crack at the code this weekend, although the
refactoring of the repository would require a committer.  Maybe even a

> Anyway, if it comes down to using an expression library, I'd argue
> for JEXL over commons-el because JEXL supports method invocation,
> which is incredibly handy.

I've never used JEXL, but method invocation sounds cool.  I have never
had a case where I needed it, but it sounds cool anyway.  I will look
at it before I go Creating any patches.

> Joe
> --
> Joe Germuska
> "Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message