cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From volker.schm...@basf-it-services.com
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 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.
>

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
="{1}"/>
  </map:act>
</map:match>

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.

>
>--
>Stefano.








Mime
View raw message