forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Jose Pablos <>
Subject Re: Moving map:components to the root sitemap?
Date Tue, 05 Aug 2003 14:59:12 GMT

Jeff Turner wrote:
> AFAIK the component definitions in subsitemaps override those in
> sitemap.xmap, so I don't see how this could be the case?
> In fact I'd imagine quite the opposite happening; people modify the
> component definition in sitemap.xmap, and this has unanticipated effects
> in subsitemaps.

I put an example,

If I modify the quality attrb for this component on sitemap.xmap:

<map:serializer name="svg2jpeg" mime-type="image/jpeg" 
    <parameter name="quality" type="float" value="0.75"/>

I would expect all my images to have  0.75 quality right?

but on resources.xmap _used_ to be this definition:

<map:serializer name="svg2jpeg" mime-type="image/jpeg" 
    <parameter name="quality" type="float" value="1.0"/>

So that would be overwrite and the images will still the same quality.

that is what I call an unanticipated side effect.

The change I made reduce complexity, I removed definitions that were the 
same, and I put them on sitemap.

>>> I'd have thought it makes more sense to define the component
>>>where it is used.  Putting subsitemap component definitions in the root
>>>sitemap breaks the separation of concerns between sitemaps.
>>But allows to have all the definitions in one place.
>>> For
>>>instance, I now have to have nekodtd, the Chaperon lexer, the profiler
>>>and various other seemingly irrelevant components cluttering my
>>>sitemap.xmap.  Currently, the sitemaps are designed so that if any
>>>modifications are required, they can probably be done in sitemap.xmap,
>>>not touching the other sitemaps.  But now that the component definitions
>>>are all in sitemap.xmap, any time it is overridden, it prevents
>>>subsitemaps from being painlessly upgraded.
>>If the definition have not been changed on the submap then it is not 
>>beeen upgrade, because it use the old definition. That is exactly what 
>>we wanted to avoid.
> I don't understand.  I'm talking about when the definition _has_ changed
> in a subsitemap.
> For example, say we introduce support for a new Wiki format in
> forrest.xmap, that requires a new component,
> org.apache.forrest.WikiTransformer.  If we define this component in
> sitemap.xmap, what happens to everyone with customized sitemap.xmaps?
> Their site will break, because their customized sitemap does not define
> the new component.

ok, If you have ovewrite forrest.xmap you will be in the same case, the 
new Wiki format will not work either. Moving definitions to sitemap will 
reduce the chances of a non-defined component.

>>You think you upgraded and you are using the old stuff.
> Yes, that's exactly the problem I had today, and many others are going to
> have.  I found that menu.xmap broke, because my overridden sitemap.xmap
> didn't define a component.

So to avoid this you want to had the same definition more than once?, I 
looked on the issue with the menu.xmap and I think that the config 
component can be used in more than one map, so it makes sense to have it 
on sitemap.

I rather have an error when I upgrade than a side effect that I am not 
aware of.

Let me know what you think,


View raw message