cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/a/ blocks/cocoon-core-sample/cocoon...
Date Wed, 09 Jan 2008 19:23:25 GMT
Ralph Goers pisze:
> Rats. Sorry. I was trying to squeeze that in when I had free time and I
> just get so used to skipping the tests since every time I've tried to
> run them my build has failed. I shouldn't have assumed they were still
> not working.
> To be honest when I was working on this I was just very frustrated at
> how much more complicated 2.2 is and was just looking for the simplest
> way to get VariableResolvers working everywhere like it does in 2.1.

I don't agree that expression handling is more complicated in 2.2 than it is in 2.1. The only
complicated bit is a joint-point between sitemap engine (based on many "hacks" like local
managers) and expression language module (which is purely Spring-based).

> I
> spent hours over the weekend trying to get all this working. I should
> have raised some of these issues on the list before I checked it in:
> 1. Why on earth is VariableResolverFactory doing a lookup on
> StringTemplateParserVariableResolver.ROLE? Spring is supposed to free
> you to allow any implementation of an interface - or is
> StringTemplateParserVariableResolver the only acceptable implementation?
> (In which case, why is it even configurable via Spring?). It seems to me
> this should be replaced with VariableResolver.ROLE.

Actually, it is StringTemplateParserVariableResolver where you can choose which implementation
StringTemplateParser you want to use for resolving expressions.

So dependency graph looks like:

                |                                                     |
LegacySitemapStringTemplateParser                       DefaultStringTemplateParser
                |                                                     |
                |                                                     |
        VariableResolver                                       ExpressionFactory
(used for resolving old sitemap expressions             (creates expression object
 like {input-module:something})                          that uses JXPath, Jexl, etc.
                                                         for resolving new-style

So there is still choice of implementation but at the other level, you can choose various
implementations of StringTemplateParser interface. In long term, we will get rid of VariableResolver
and will use StringTemplateParser in sitemap code. It haven't been done already because of
complicated dependencies on Avalon in sitemap.

> 2. Does PreparedVariableResolver (the resolver in 2.1) still work?  If
> it does I can have BridgeElementParser register it and then have
> SitemapElementParser replace the VariableResolver bean with
> StringTemplateParserVariableResolver. I'll give this a try and see what
> happens. Of course, it may have the same dependency problems.

PreparedVariableResolver must still work fine because LegacyStringTemplateParser is using
it all the
time now. Since I didn't touch PreparedVariableResolver I don't think it has any other dependencies
than the ones in 2.1.

If it's purely for IM testing, I think that having PreparedVariableResolver bean added directly
ok because IMs are not aware of StringTemplateParser anyway.

I suggest following readings [1][2] and links from these pages. This will give you a quite
overview of EL functionality.

> BTW - I couldn't find a reference to LegacyVariableResolver anywhere.
> Did you really mean LegacySitemapStringTemplateParser?

Yes, I meant LegacySitemapStringTemplateParser. Sorry, I was writing in a hurry.


Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

View raw message