The following snippet is the guide example for the first two questions.
<map:pipeline>
<map:match pattern="sub/*">
<map:mount check-reload="yes" src="sub/sitemap.xmap"
uri-prefix="sub"/>
</map:match>
<map:handle-errors>
<map:transform src="errors.xsl"/>
<map:serialize status-code="500"/>
</map:handle-errors>
</map:pipeline>
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?
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?
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]>
- Re: General sitemap questions Miles Elam
- Re: General sitemap questions Miles Elam
- Re: General sitemap questions Miles Elam