cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <mi...@pcextremist.com>
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.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message