cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Re: VariableResolver doesn't resolve Variables inside ModuleVariable
Date Sun, 18 May 2003 12:21:24 GMT

on 5/17/03 12:10 PM 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
>> My idea was, using an InputModule which defines this mapping. The
>> is, that in the moment it is not possible to hand over the {1} Variable
>> 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.

I agree.

I need the above feature inside the development environment because I want
to map some modules (>20) of a really big application to different Eclipse
projects. This modules are developed by different developers and I will
test/modify this application without the need to redeploy the hole webapp.
So each module has it's own Sitemap/Code and it's own location inside the
eclipse workbench. I also have written an WebappLoader for Tomcat to make
it possible to add an eclipse project to the WebAppLoader of Tomcat without
moving the jar to WEB-INF/lib or compiling the classes to WEB-INF/classes.
So I can modify/test the application without doing a new build. This really
improve the development cycle.
Is this also possible if we have blocks? I really like development without
doing a deployment if I changed the code or resource ;-) I think we also
need to think about the differences between development an production.

> 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)

I don't really need the above feature, I can change the above using an
action ;-) I know, you don't like actions ;-)

<map:match pattern="*/**">
  <map:act .....>
   <map:mount check-reload="yes" src="{return-param-of-action}/" uri-prefix

I have no real use case, but I think it really make sense to allow puting
an sitemap variable as an argument of an InputModule. The same for nesting
variable expansion.


View raw message