cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: VariableResolver doesn't resolve Variables inside ModuleVariable
Date Sun, 18 May 2003 18:08:50 GMT
on 5/18/03 7:21 AM wrote:

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

the perfect scenario for blocks :-)

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

Oh, yes, I see this.

> Is this also possible if we have blocks? 

I don't see a reason why not.

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

Yes totally. But first I want to get it working, then we polish it ;-)

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

This has been proposed several times but we always could go without it.
I would not like to add such a key change in paradigm right before a
release. So, if you can go without it for now, I'd refer this discussion
for post-2.1.



View raw message