forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bowe, Bastian" <Bastian.B...@astrium.eads.net>
Subject RE: configuration of plugins (WAS:Wiki and UTF-8/non-latin-1)
Date Fri, 18 Feb 2005 13:18:10 GMT
> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@apache.org] 
> Sent: Friday, February 18, 2005 1:54 PM
> Bowe, Bastian wrote:
> > 
> >>-----Original Message-----
> >>From: Ross Gardler [mailto:rgardler@apache.org]
> >>Sent: Wednesday, February 16, 2005 2:07 PM
> > 
> > ...
> > 
> >>Configuration of plugins is not possible yet, we have
> >>discussed various 
> >>solutions over on the dev list, but none have been 
> >>implemented yet.
> > 
> > 
> > Haven't followed that discussion but I've created a plugin that 
> > manages configuration by reading (or to use cocoon term: 
> generating) 
> > xml files from {project:doc}/yourPluginConfigFile.xml
> 
> Could you post (on the dev list - I've set the reply-to field on this 
> mail) a few details about how your system works and what kind of 
> facilities it offers. At present we don't have anything 
> working and your 
> implementation might well be the start of something concrete.

Actually my configuration file is not customizing the plugin it is
customizing forrest. But it should work for plugins too.

I'm working on a project which I called Jenny (you know, forrest's
girlfriend :). It is something very similar to forrest and of course based
on it. Forrest has too many configuration options for my target audience. So
I created a forrest plugin, among some others, that supplies forrest with a
skinconf equivalent that is much less feature rich.

My plugin just overwrites the forrest skinconf related pipeline (actually
this is done in a speperate plugin to keep the version dependency to special
forrest pipelines as seperate/small as possible) with a pipeline that calles
the following pipeline to actually get the skinconf:

      <map:match pattern="skinconf">
        <map:select type="exists">
          <map:when test="{project:skinconf}">
            <!--
                use skinconf from project
            -->
            <map:generate src="{project:skinconf}" />
          </map:when>
          <map:otherwise>
            <!--
                generate skinconf with settings from jennyconf.xml
            -->
            <map:generate
 
src="{forrest:plugins}/foo.forrest.plugin.jennyconf-internal/resources/conf/
skinconf.xml"/>
            <map:transform type="xinclude"/>
          </map:otherwise>
        </map:select>
        <map:serialize type="xml"/>
      </map:match>

If a skinconf.xml exists it will use that as it works with forrest. If it
doesn't exist it will use a default skinconf.xml. Here is an excerpt from
that file:
<skinconfig>
...
  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="cocoon:/jennyconf#xpointer(jennyconfig/skinconfig/*)"/>
</skinconf>

A jennyconf could look like this:
<?xml version="1.0"?>
<!--
TODO: Write a dtd that just allows the elements missing in
{forrest:plugins}/foo.forrest.plugin.jennyconf-internal/resources/conf/skinc
onf.xml
<!DOCTYPE skinconfig PUBLIC "-//APACHE//DTD Skin Configuration
V0.6-3//EN" "http://forrest.apache.org/dtd/skinconfig-v06-3.dtd">
-->
<jennyconfig>
  <skinconfig>
    <project-name>MyProject</project-name>
    <project-description>My Project Description</project-description>
	<project-logo>images/project.png</project-logo>
  </skinconfig>
</jennyconfig>

As you probably already guessed you should be able to use that technique to
control any other pipeline of your plugin in all the ways cocoon offers you
(e.g. using xslt transformer). Hope I could explain the idea...

Regards

Bastian

Mime
View raw message