cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: MountTableMatcher
Date Mon, 17 Nov 2003 17:18:02 GMT
Upayavira wrote:

> Sylvain Wallez wrote:
>

<snip/>

>> Sorry to jump in late (just saw your "I commited it!" message), but 
>> what's the need for this?
>
>
> I see the potential for your matcher going further than you seemed to 
> envision.
>
> My patch is aimed to allow the user to choose the location of the 
> mount-table file without the need to change the root sitemap itself.
>
> This means that the matcher can be used, without changing the root 
> sitemap, with the webapp deployed somewhere other than in 
> build/webapp, which is certainly my custom.
>
> In my deployed sites, I simply add a mount right at the beginning of 
> the root sitemap, which matches on "**", thus overriding anything else 
> in the root sitemap (other than handle-errors, possibly).
>
>> MountTableMatchers allows externally-defined indirections to be 
>> plugged into a sitemap, and you add another level of indirection 
>> through the build property.
>
>
> The indirection allows the table itself to be somewhere else, yes.
>
>> Sorry, but this really seems FS to me as I think nobody will ever 
>> change the build property, but just modify the sitemap statement...
>
>
> Depends. I find it frustrating to have to re-patch the sitemap every 
> time I rebuild Cocoon. This way, that becomes largely unnecessary.
>
>> Moreover, I don't understand the "live enviromnent" argument, as it's 
>> not desirable at all, IMO, to deploy the main samples sitemap "as is" 
>> on a live enviromnent. All the mounts it contains are either highly 
>> samples-related or automounts that are dangerous in a production 
>> environment.
>
>
> I would build my Cocoon for deployment without the samples and would 
> create my own mount table. My own mount table would, as you have 
> already said, survive a clean build of Cocoon, so I see no problem here.
>
> The major job here was to get the Ant task to be able to do patches 
> using Ant properties. That is a useful feature in itself, which I 
> think should stay.


This feature is definitely useful.

> Beyond that, if you and others feel that the sitemap patch is 
> overkill, I'm happy to remove it and just use it on my own systems 
> (after all, that is only one file on src/confpatch).
>
> Does this explain better what I had in mind with this? For me I see it 
> as useful, even in a live environment, but certainly with the samples 
> excluded.


Ok, I understand your use case, and I realize that I underestimated the 
unsefulness of xconftask outside of Cocoon's build environment.

So let's keep it there, and sorry for ranting :-/

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message