cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: VariableResolver doesn't resolve Variables inside ModuleVariable
Date Sun, 18 May 2003 01:38:06 GMT
on 5/17/03 12:10 PM volker.schmitt@basf-it-services.com wrote:

> Hi,
> 
> I have the following use case inside the Sitemap:
> 
> <map:match pattern="*/**">
>   <map:mount check-reload="yes" src="{mount:{1}}/" uri-prefix="{1}"/>
> </map:match>
> 
> look at the source attribute "src="{mount:{1}}/"
> I want to define a mapping between the URI space and the Filesystem space.
> My idea was, using an InputModule which defines this mapping. The problem
> is, that in the moment it is not possible to hand over the {1} Variable to
> the InputModule.
> 
> If there is no other possibility I can create a patch
> (PreparedVariableResolver) to make this possible.
> 
> What do you think?

"real blocks"(tm) will make any virtual-file-system practice
deprecatable (or, at least, I hope so). I tend to be against, by
default, to any complexity addition to the sitemap behavior that doesn't
 represent a need that can't be met otherwise and, in this case, I think
blocks do cover that.

Now, this said, blocks are not there and will not be for a while, so my
point might be very moot if you need this functionality right now and I
totally understand this is the case.

This said, is there any other real-life usage of the above? if so, I
would be more inclined to vote a +1 and let it go, but for now I remain
-0 because it might turn out to be a practice to discouradge in the
future and I don't want to add stuff when we already know we are going
to deprecated it later.

But it's also true that this is a much more general concept than just
virtualizing the file system space. This is why I'm asking for other
reasonable usage of such nesting variable expansion behavior (which,
AFAIK, is not done anywhere else in the sitemap)

-- 
Stefano.



Mime
View raw message