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?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.
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?
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?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).
Would errors in the subsitemap be caught in the parent's error handlers if the subsitemap error was not caught by its own handlers?
-----
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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
