Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
<snip/>
Btw. The only code I use from the treeprocessor is the variable
resolver stuff. I think this code is of general enough interest to
dedicate its own subpackage for (away from treeprocessor). I noticed
Carsten currently has duplicated that code in the portal block. WDYT?
I use the variable resolver also ;-) For now I changed it so that it
accepts both ServiceManager and ComponentManager.
IMO, we should not make a component with the variable resolver, but
some utility class providing some common base resolution (e.g. input
modules) yet allowing extensions in the places where it is used (e.g.
named anchors and parent stack in the sitemap).
I feel the same way. Your plan sounds like a clean solution to me.
Should nested variable resolving be optional though? Perhaps in cases
where it is not needed it would optimize performance to turn it off?
It might be an option when getting a variable resolver from the
factory or else when calling the resolve method on a variable resolver.
Although I have no figures to put behind it, my impression is that the
nested variable resolver would not be any less performant that its
predecessor. It just makes sensible use of a stack and reverse polish
notation (or some such).
Upayavira
