[Springframework-developer] Re: OGNL

[Rob H. <ro...@ca...>]

Guillaume,

How does this work when the expression references a bean that has not yet 
been assembled by Spring - that is how does this example handle bean 
interdependencies. It is possible that an expression will change the beans a 
bean depends on and this would not be handled by the standard dependency 
resoution algorithm. That was the purpose behind my getDependencies() method 
so that the expression could add to the dep tree. 

Rob 

Guillaume Poirier writes: 

> In the prototype I sent to this list, I did something similar, except that 
> I assumed that we would want the expression compiled once when reading the 
> XML file, and then evaluated multiple times if needed.  However, in your 
> example, you would need to give a context to the expression evaluator.  
> And I'm not sure what's the purpose of the getDependencies() method, and 
> how would you implement that with OGNL? 
> 
> My prototype has an Expression interface as shown below, where the 
> expression is expected to be compiled in the constructor, and then 
> evaluated when a specific context is provided in the resolve method. 
> 
> public interface Expression {
>  public Object resolve(ListableBeanFactory factory);
> } 
> 
> The OGNL implementation looks like this: 
> 
> public class OgnlExpression implements Expression {
>  private Object expr;
>  public OgnlExpression(String value) {
>    try {
>      expr = Ognl.parseExpression(value);
>    } catch (OgnlException e) {
>      throw new BeanCreationException("Failled to parse OGNL expression", 
> e);
>    }
>  }
>  public Object resolve(ListableBeanFactory factory) {
>    try {
>      Map ctx = new OgnlExpressionContext(factory);
>      return Ognl.getValue(expr, ctx, (Object) null);
>    } catch (OgnlException e) {
>     throw new BeanCreationException("Failled to resolve OGNL expression", 
> e);
>    }
>  }
> } 
> 
> The class OgnlExpressionContext extends OgnlContext which extends a map, 
> it exposes the beans in the ListableBeanFactory to the OGNL engine. 
> 
> The original post was at : 
> http://article.gmane.org/gmane.comp.java.springframework.devel/6076, and I 
> attached the prototype to this email, since gmane doesn't seem to keep the 
> attachements.  The patch was made on a Spring's CVS of a month ago though, 
> but it still seems to work with an up to date CVS. 
> 
> Guillaume 
> 
> ----- Original Message ----- From: "Rob Harrop" <ro...@ca...>
> To: <spr...@li...>
> Sent: Saturday, November 06, 2004 10:38 AM
> Subject: [Springframework-developer] Re: OGNL 
> 
> 
>> I like the idea of having am <expr> tag for something like <expr 
>> type="ognl">.  In the code we could have something like: 
>> 
>> public interface ExpressionEvaluator {
>>   String[] getDependencies(String expr);
>>   Object evaluate(String expr);
>> }
>> Then we could have multiple implementations for the ExpressionEvaluator 
>> interface for OGNL, Groovy etc.
>> Rob
>> Rod Johnson writes:
>>> <script lang="ognl"> perhaps I think it would be good for the mechanism 
>>> to be extensible. Guillaume Poirier wrote:
>>>>> I am somewhat more attracted to the idea of using  a prefix on the 
>>>>> value inside the <value> tag.
>>>>  While I admit that it would be unlikely to cause problem, using a 
>>>> prefix in a value tag is not 100% backward compatible.  Someone could 
>>>> be using such prefix currently for a String that should be analysed by 
>>>> once injected, rather than by Spring.  And I personally find an <ognl> 
>>>> tag more intuitive for the user.  It's also somewhat easier to 
>>>> implement, not that it really matters much I guess.
>>>>> My other concern is with the  speed of OGNL.
>>>> 
>>>> Adding OGNL support doesn't prevent from adding supports for other 
>>>> expression languages. :-) Guillaume ----- Original Message ----- From: 
>>>> "Colin Sampaleanu" <col...@ex...>
>>>> To: <spr...@li...>
>>>> Sent: Friday, November 05, 2004 4:46 PM
>>>> Subject: Re: [Springframework-developer] OGNL
>>>>> Rob, No Spring committer has done any work that I know of. However, if 
>>>>> you look at the thread with the subject "PropertyPathFactoryBean", on 
>>>>> Oct. 6th Guillaume Poirier posted some OGNL patches. You might want to 
>>>>> read his email, and take a look at my reply too. Using a new element 
>>>>> (<ognl> was Guillaume's suggestion) would work in a completely 
>>>>> backwards compatible fashion. I am somewhat more attracted to the idea 
>>>>> of using a prefix on the value inside the <value> tag. My other 
>>>>> concern is with the speed of OGNL. OGNL is quite nice, it's heavily 
>>>>> used in Tapestry and I found it a lot better than say the JSTL's 
>>>>> expression language. However, v2.x anyways, is not a speed demon. I'd 
>>>>> like to also compare it to something like Janino:
>>>>>   http://www.janino.net/
>>>>> in terms of best fit for Spring... Colin Rob Harrop wrote:
>>>>>> All, Has anyone started work on the OGNL support yet. I have no plans 
>>>>>> for the weekend and I need to do something other than JMX :) Rob