Design new configuration system

• Key: FOR-588
• Type: Task
• Status: Open
• Priority: Critical
• Assignee: Unassigned
• Reporter: Ross Gardler
• Component/s: Core operations
• Fix Version/s: 0.10

Description

We need a new config system for Forrest for various reasons: the initial config system was known to be limited; to enable the specification of multiple Forrest sites within a single instance of Forrest; to accommodate the changes brought about by forrest:views, themes, and plugins.

Comments

[Ross Gardler]

Some discussion:

http://marc.theaimsgroup.com/?t=112299875300003&r=1&w=2

[Ross Gardler]

An RT on how to integrate multiple sites:

http://marc.theaimsgroup.com/?l=forrest-dev&m=112387459426160&w=2

[David Crossley]

This issue is the result of an ApacheCon discussion, more, including links to the original ApacheCon Summaries at :- FOR-618 "Create issues for items discussed at Apachecon"
 
Some devs had an initial discussion. The notes are in SVN at
http://svn.apache.org/repos/asf/forrest/events/apachecon-eu-2005/

[David Crossley]

NOTE: For any users thinking ("oh no, the next forrest will be hard to upgrade because of fundamental changes in the way it is configured", don't worry. We will (most likely) provide tools to facilitate this upgrade, we will need them ourselves anyway).

[Ross Gardler]

Using locationmap as a config system: http://marc.theaimsgroup.com/?l=forrest-dev&m=112827771411900&w=2

[Ross Gardler]

A new set of properties can now be defined in a "forrest.properties.xml" file in the root of the project. These properties are not defined in forrest.xconf, thus any property can be defined in this file. This enables plugins to define their own property values. Although at the time of writing functionality is minimal.

The format of the file is:

<?xml version="1.0" encoding="UTF-8"?>
<properties>
       <property name="daisy.navigation.docID" value="1208"/>
</properties>

Properties are retrieved in the sitemap and the locationmap (untested) using {project:PROPERTY.NAME}.

Currently there is no mechanism for loading defaults for plugin properties. This needs to be added.

In addition to plugins being able to define properties that can be overridden by the project properties file this addition enables us to remove the need to define properties in forrest.xconf.

[Ross Gardler]

We have a prototype solution in place for 0.8-dev

This solution solves the immediate problems for configuring plugins.

Reducing priority and moving to 0.9 when we will complete this functionaliy.

[Ross Gardler]

The process for doing this will change when the new property system is adopted (being prototyped in 0.8-dev)

[Thorsten Scherler]

The dispatcher needs an aggregation of forrest.properties.xml.

[David Crossley]

More discussion is at:
 RT: Storage of Properties
 http://marc.info/?t=120370236700002