Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 61923 invoked from network); 10 Jun 2005 17:53:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Jun 2005 17:53:35 -0000 Received: (qmail 1575 invoked by uid 500); 10 Jun 2005 17:53:31 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 1530 invoked by uid 500); 10 Jun 2005 17:53:30 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 1517 invoked by uid 99); 10 Jun 2005 17:53:30 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of razmaspaz@gmail.com designates 64.233.184.207 as permitted sender) Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.207) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 10 Jun 2005 10:53:28 -0700 Received: by wproxy.gmail.com with SMTP id 71so768007wra for ; Fri, 10 Jun 2005 10:52:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AP2/KoqkOfSXWqqZR+4cffYTbRHXsBjQES2FIzs/EIZNNRejNkw22Z0tayztAdau1zL3dGb8eu4prVx4WUrkGVYRWyPkiTyyaHtVrjOuS+xmUDdMhaRadrVDbf3vsZMfObhR+yoaO8+8SGaJPzZ3Mv10BoFViwJN5yFjFQAmJlo= Received: by 10.54.22.33 with SMTP id 33mr1104748wrv; Fri, 10 Jun 2005 10:52:35 -0700 (PDT) Received: by 10.54.68.18 with HTTP; Fri, 10 Jun 2005 10:52:35 -0700 (PDT) Message-ID: <1d0ae860506101052524f36fd@mail.gmail.com> Date: Fri, 10 Jun 2005 12:52:35 -0500 From: Michael Rasmussen Reply-To: Michael Rasmussen To: Joe Germuska Subject: Re: [Chain] adding EL support Cc: Jakarta Commons Developers List In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1d0ae8605061009234b9c77a5@mail.gmail.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. >=20 > 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. >=20 > 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. >=20 > 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. =20 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 vote? >=20 > 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. >=20 > Joe >=20 > -- > Joe Germuska > Joe@Germuska.com > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org