forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Add support for Googles sitemap protocol?
Date Wed, 03 Aug 2005 22:01:29 GMT
Rasik Pandey wrote:
> 
>  > To answer you specific question. Anything defined in a plugin sitemap
>  > (internal or otherwides) has the same access limitations that you will
>  > find in any Cocoon sitemap. That means:
> 
> Which means views are bound to the sitemap in which they are defined and 
> leaves us two options, redeclare all pertinent pipelines in the 
> internal.xmap
> 
> OR add these two pieces to root Forrest sitemap.xmap:
> 
> <map:serializers>
> <map:serializer name="links" 
> src="org.apache.cocoon.serialization.LinkSerializer">
> <encoding>ISO-8859-1</encoding>
> </map:serializer>
> </map:serializers>
> 
> <map:views>
> <map:view name="links" from-position="last">
> <map:serialize type="links"/>
> </map:view>
> </map:views>
> 
> So the LinkStatusGenerator will be able to access the requisite 
> information. I am NOT a fan of  either approach :( as neither is a neat 
> implementation.

I agree neither solution is neat. For version 0.1 of your plugin I would 
redefine all pertinent pipelines in the internal.xmap. The longer term 
solution will be to use the shiny new sitemap block mounting mechanism 
once we can upgrade Cocoon in Forrest. As I think I mentioned before 
this allows a level of inheritance in sitemaps, complete with the 
ability to override items in the super sitemaps. It even allows for 
multiple inheritance.

>  > What properties do you want?
>  >
>  > As a hint you can access most of the properties with {project:foo} where
>  > foo is defined within forrest.xconf
> 
> You mean within the "forrest.properties" file and NOT the 
> "forrest.xconf" file, right?

No, I meant forrest.xconf, but my response was certainly confusing. Let 
me try and explain.

Within forrest.xconf there are a properties set that can be accessed 
with {forrest:foo} and another set that are accessed with {project:bar}. 
The values of these properties are (in some cases) set in 
forrest.properties. In other words the user is not supposed to edit 
forrest.xconf

See the element <component-instance name="defaults" 
class="org.apache.forrest.conf.ForrestConfModule"> for the {forrest:foo} 
properties and <component-instance name="project" 
class="org.apache.forrest.conf.ForrestConfModule"> for the {project:foo} 
properties.

The @foo.bar@ are tags that are replaced by Ant when Forrest is 
launched, but in the main they have the same names as properties set in 
forrest.properties.

Ross

Mime
View raw message