cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Kuhnle <li...@kuhnle.net>
Subject Re: Manually specifying a mounted sub sitemap's context
Date Sat, 09 Apr 2005 20:27:25 GMT
Sylvain Wallez <sylvain@apache.org> 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




Mime
View raw message