There is already support for doing this by calling ExpressionEvaluatorManager.parse(string, expression, ...), we just need to make sure that when those values are evaluated that the parse method is called, not the evaluate method. There may be places where the "expression" method is being used since I introduced the parse method later on.
Cheers,
Ross Mason
CTO, Founder
MuleSource Inc.
http://mulesource.com |
http://blog.rossmason.com
On Fri, Oct 24, 2008 at 6:38 PM, Andrew Perepelytsya
<aperepel@...> wrote:
The current expression evaluators framework is great, but we could push it even further. We're _almost_ at a point where dynamic properties of the endpoints are possible, so e.g. things like this would work:
<file:outbound-endpoint path="#[mule:workingDir]/out" outputPattern="#[foo:dummy]-#[function:count]"/>
However, I faced the limitation of the current evaluator - expressions can't be nested inside a literal string. So, given the #[mule:workingDir]/out expression, the evaluator would get confused, as it expects _only_ #[mule:workingDir]. Just to have another angel, consider a headers evaluator, like #[header:X-Forward]-QA to be added to the http traffic. Still not possible.
So the proposal is to enhance the evaluators to allow such nested exceptions and encapsulate this logic in it. The next natural step would be to allow multiple evaluations in a single expression, for now this is not consistent and scattered throughout the code (e.g. "#[foo:bar]-#[mule:serverId]-data").
Andrew
