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 service
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 of
StringTemplateParser you want to use for resolving expressions.
So dependency graph looks like:
VariableResolverFactory
|
|
StringTemplateParserVariableResolver
|
|
+---------------------+-------------------------------+
| |
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
expressions)
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 is
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 good
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.
[1]
http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/1404_1_1.html
[2]
http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/1407_1_1.html
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
