forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Moving map:components to the root sitemap?
Date Tue, 05 Aug 2003 22:47:53 GMT
On Tue, Aug 05, 2003 at 04:59:12PM +0200, Juan Jose Pablos wrote:
> 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.

Yes, I see your point.  There are a few components ('html', 'xml',
'xslt') which ought to have one, common definition.  So in general we
should follow your suggested rule of putting components in sitemap.xmap
if they are shared across multiple subsitemaps.

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

Yes, but that is always true.  I am talking about the commonest scenario,
where I don't use the new Wiki format and haven't overridden
forrest.xmap.  I don't care about new formats; I just want my existing
site to work.  Now it doesn't work _at all_ (not just one unsupported
format), because the new forrest.xmap relies on a component that my
sitemap.xmap doesn't provide.  For example:

X [0] index.html        BROKEN: Type 'config' is not defined for 'select'
at
file:/home/jeff/src/jira-docs-cvs/web/build/tmp/context/menu.xmap:38:35


> Moving definitions to sitemap will reduce the chances of a non-defined
> component.

You're forgetting that the sitemaps were designed so that only
sitemap.xmap is ever likely to need customization.  Subsitemaps define
pipelines, but don't 'bind' them to a specific URL.  For example,
faq.xmap matches:

    <map:match pattern="**.xml">
      ...
    </map:match>

This is only 'bound' to the URL 'faq.html' in sitemap.xmap:

<map:match pattern="**faq.xml">
  <map:mount uri-prefix="" src="faq.xmap" check-reload="yes" />
</map:match>

Let's say I want to treat
src/documentation/content/xdocs/foo/questions.xml as a FAQ.  I don't need
to touch faq.xmap; I just redefine the sitemap.xmap matcher:

<map:match pattern="foo/questions.xml">
  <map:mount uri-prefix="" src="faq.xmap" check-reload="yes" />
</map:match>

So sitemap.xmap (not subsitemaps) really defines the whole URI space, and
so sitemap.xmap is most likely to be overridden.

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

Yes, if necessary.  Which is better: to duplicate a definition, or have
everyone's site break whenever we change a subsitemap?  What is the cost
of a duplicated definition?  In the worst case, a change to sitemap.xmap
has no effect.  The alternative is to _guarantee_ things breaking.

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

Yes, it _can_ be used in multiple places, but currently it is used in
only one.  Things should be scoped locally until the necessity for global
scoping becomes apparent.

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

As a user, I'd rather have my site _not_ be broken every time someone
adds a new feature to Forrest ;)


--Jeff

> 
> Let me know what you think,
> 
> Cheers,
> Cheche
> 

Mime
View raw message