Sylvain Wallez <[EMAIL PROTECTED]> wrote on 09.04.2005 20:51:41:
>
> That being said, there's another issue about the proposed "context"
> attribute: who's responsibility is it to specify on what context will a
> sitemap operate? Is it the <map:mount>'s responsibility or the sitemap's
> own responsibility?
>
> In other words, should it be:
>
> <map:mount src="foo/bar/" context="baz"/>
> and
> <map:sitemap>
>
> or
> <map:mount src="foo/bar/"/>
> and
> <map:sitemap context="baz"/>
>
>
> My feeling favors the second form, as allowing to specify the context
> externally means that understanding what a sitemap does depends on the
> mount statement.
>
Agreed, the second form is easier to understand. The first one was just
easier to implement (at least for me), since MountNode.invoke already
resolves the sitemap context. And this was the point where cocoon went
into endless recursion...
On the other hand, the first form offers one additional feature: Mounting
the same sitemap twice with different contexts. I just don't know yet if
this is a good idea...
> Hmm... same use case as Gianugo. Is it possible for these files to be
> changed directly on the live site, or is this part of some kind of
> deployment operation?
Deployment in this case being "copy file from A to B". Not pretty, but in
this case it is sufficient. No "call sitemap generator" steps that can be
forgotten or need to be automated.
> What you need here is a global variable that can be used as a prefix,
> thus writing <map:generate src="{global:base}/page.jx"/>
>
There are workarounds, but I think having the possibility to use generated
sitemaps (eiter with the context attribute, or a mounting operation that
does not crash), is generally a good thing to have and makes "sitemapping"
easier for the guys maintaining the site. And no-one can use the
"cocoon:"-protocol in the sub-sitemaps if you don't want them to.
After all, in my opinion, sitemaps combine to concerns: The definition of
resource classes ("A dynamic page of type X is generated from JX
templates, run through these transformations, and then serialized as
HTML"), the site developer's task, and the definition of resources and
their properties ("There is a dynamic page called hello.jx, it is
customized for every user, so include the user name in the cache key, and
it also has the following additional traits..."), the site maintainer's
task. Using generated sitemaps lets us separate these concerns.
Regards,
Jochen
