forrest-dev mailing list archives

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


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" 
src="org.apache.cocoon.serialization.SVGSerializer">
    <parameter name="quality" type="float" value="0.75"/>
       </map:serializer>

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" 
src="org.apache.cocoon.serialization.SVGSerializer">
    <parameter name="quality" type="float" value="1.0"/>
       </map:serializer>


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,

Cheers,
Cheche


Mime
View raw message