cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: General sitemap questions
Date Wed, 08 Jan 2003 00:15:22 GMT
Okay...answering some of my own questions...

Miles Elam wrote:

> 1) What is the accepted "correct" behavior for subsitemaps: errors in 
> subsitemaps elicit errors up the chain to parent (sub)sitemaps or 
> subsitemap validity has no bearing at all on parents?
> If foo/sitemap.xmap is missing, is not well-formed XML, or is not 
> valid, what should be the behavior for the sitemap that contains this 
> pipeline if the "sub" URLs are not requested?

I have found that if the subsitemap is missing, no error occurs.  But if 
the sitemap exists and is not valid XML, the parent handler (where the 
<map:mount .../> entry is located) is invoked on every request.  This 
may apply to all "catastophic" errors.  This seems overly reactive to 
me...  Consider the case where a hosting facility sets up a single 
Cocoon instance where the root sitemap simply mounts subsitemaps 
according to server hostname.  If a client screws up their (sub)sitemap, 
it could take everything down.

> 2) Does error handling confine itself only to the sitemap/pipeline in 
> which it's defined or does it act more like exceptions that push up 
> the chain?
> Would errors in the subsitemap be caught in the parent's error 
> handlers if the subsitemap error was not caught by its own handlers? 

Errors indeed bubble up the tree like exceptions;  However, if errors 
occur while processing the subsitemap itself, the parent handlers will 
be invoked instead (relatively obvious since the handler in the 
subsitemap would not have been available for processing).


Still curious about the other questions though.  Would dev be a better 
place to ask?

- Miles

> 3) Do subsitemaps require a components section at all?  Just defaults?
> If so, why do they need to be specified in each subsitemap?  Why not 
> inherit the defaults of the parent if they're not specified?  I ask 
> because I'd like subsitemaps to be as small and simple for beginners 
> as possible.  Since their choice of components are determined by 
> parents, both scenarios have a parent content dependency.
> 4) Is there any way (or proposed way) to specify that a sitemap 
> resource have a fixed-duration cache validity?
> Can you specify that a relatively dynamic resource should have its 
> internal cache validity only expire after a fixed period of time, like 
> an hour or a day?  This is not just limited to headers (like the 
> current "expires" attribute in 2.1), but rather for any resource.
> A contrived example:
>    <map:match pattern="stockquotes.xml">
>      <map:generate type="serverpages" src="data_from_sql_taglib.xsp"/>
>      <map:serialize type="xml"/>
>    </map:match>
>    <map:match pattern="generalpublic.html">
>      <map:generate src="cocoon:/stockquotes.xml" expires="1 hour"/>
>      <map:transform src="stocks2html.xsl"/>
>      <map:serialize type="html"/>
>    </map:match>
>    <map:match pattern="subscribersonly.html">
>      <map:generate src="cocoon:/stockquotes.xml" expires="5 minutes"/>
>      <map:transform src="stocks2html.xsl"/>
>      <map:serialize type="html"/>
>    </map:match>
>    <map:match pattern="goldsubscribersonly.html">
>      <map:generate src="cocoon:/stockquotes.xml"/>
>      <map:transform src="stocks2html.xsl"/>
>      <map:serialize type="html"/>
>    </map:match>
> Same resource...different cache granularity.  It seems to me that this 
> would be especially useful for aggregations -- especially aggregations 
> of dynamic data.  ...or is this technically in opposition to (and 
> blocked by) the existing cache model that's based on hash keys?  I 
> think it would also solve a lot of the problems with complexity in XSP 
> scripts since some authors wouldn't have to worry about putting cache 
> validity (whose API has changed) in their code which may otherwise 
> have just been taglibs.
> Answers or clues to any or all of these questions would be greatly 
> appreciated.  :)
> - Miles

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message