You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Miles Elam <mi...@pcextremist.com> on 2003/01/07 22:04:00 UTC
General sitemap questions
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: General sitemap questions
Posted by Miles Elam <mi...@geekspeak.org>.
*sigh* ... Feeling foolish for wasting bandwidth...
>> 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.
>
Please disregard. The components section isn't necessary in the builds
I am using (v2.1).
- 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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: General sitemap questions
Posted by Miles Elam <mi...@pcextremist.com>.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>