Return-Path: 
 <commons-dev-return-63782-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 37109 invoked from network); 2 Dec 2004 23:08:35 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 2 Dec 2004 23:08:35 -0000
Received: (qmail 36047 invoked by uid 500); 2 Dec 2004 23:08:33 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 35975 invoked by uid 500); 2 Dec 2004 23:08:32 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 35961 invoked by uid 99); 2 Dec 2004 23:08:32 -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 craigmcc@gmail.com designates
 64.233.170.194 as permitted sender)
Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.194)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 02 Dec 2004 15:08:32 -0800
Received: by rproxy.gmail.com with SMTP id g11so37338rne
        for <commons-dev@jakarta.apache.org>;
 Thu, 02 Dec 2004 15:08:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=jJBW8lS/s8EM5c4ewgKCpbttCtdbcKFfk3fj5US2Nxtzg9i4G4y9gCNYZS0b+VzohI1p6Cdoy0jVdahzGR8uoEB62TnjtuVZUfp2tNdaHT8/5Nt/AXncMwHdOLfAODK3Ngm667/Fjp52KPk4q5fSsM7wcS1Yc+hNnS03hfdVRrM=
Received: by 10.38.90.7 with SMTP id n7mr161227rnb;
        Thu, 02 Dec 2004 15:08:30 -0800 (PST)
Received: by 10.38.72.38 with HTTP; Thu, 2 Dec 2004 15:08:29 -0800 (PST)
Message-ID: <f8b39ace041202150831347a11@mail.gmail.com>
Date: Thu, 2 Dec 2004 15:08:29 -0800
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [chain] add expression evaluation?
In-Reply-To: <a06200712bdd54945c66c@192.168.0.3>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <a06200712bdd54945c66c@192.168.0.3>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Interestingly, Digester already supports the expression replacement
mechanics (see org.apache.commons.digester.Substitutor), so it ought
to be really easy to do this kind of thing, and an elegant solution to
boot.

I'm +1 for it.

Craig


On Thu, 2 Dec 2004 16:40:31 -0600, Joe Germuska <joe@germuska.com> wrote:
> In a discussion on the struts-user list, I got around to describing a
> configuration format which made me wonder if folks would tolerate
> some kind of expression evaluation engine in chain.
> 
> The musing repeated below:
> 
> At 1:57 PM -0600 12/2/04, Joe Germuska wrote:
> >I think you could find the view processor command by using the
> >standard Chain "lookup action".  Well, out of the box, its "nameKey"
> >property would depend on some String value being placed into the
> >context under a certain key, and as it is now, we're talking about
> >using a String property of an Object in the context under a certain
> >key.  If we gave the LookupCommand an expression language (JEXL,
> >perhaps?), then we could do something like this, which seems cool:
> >
> >       <command
> >           className="org.apache.commons.chain.generic.LookupCommand"
> >         catalogName="struts-view-preprocess"
> >                nameKey="${context.forward.name}"
> >            optional="true"/>
> >
> >or possibly work some magic to make the "context" prefix assumed.
> >Anyone  have an opinion about adding a JEXL dependency to Chain, or
> >whether this would be best left to a Struts subclass of
> >LookupCommand?
> 
> Ideas?  I'm not sure right now of the scope of this proposal -- is it
> just for the LookupCommand?  Is it somehow implemented more widely?
> How can you do that when Chain is first-and-foremost an API?
> 
> I can certainly see some of these questions leading folks to throw up
> their hands and say "let's just keep it simple."  There's no critical
> reason to add this dependency to the core, but when you think about
> the expressive power it would provide in the config files, it seems
> pretty cool.
> 
> Joe
> 
> --
> 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
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org