Those who were in Stuttgart will remember (I hope) a discussion about
the future of our config system. Anil took the time to go through the
podcast of the session and pull out the conclusions [1]
One of the main points in this discussion was that we need to move the
config stuff out of forrest.xconf since a change to that file requires
that the server be restarted, not a good thing in a production environment.
In addition, having the config in forrest.xconf prevents Forrest from
hosting multiple sites.
My proposal at the time was to use the locationmap. At the time it was
not possible because LMs could not mount other LMs. However, Tim has
sorted this out for us, so we can start thinking about this move. Since
Thorsten is also moving views to use the LM everything should be in
place soon.
Now that I have started to convert our sitemaps to use the LM I hope
that it is a little clearer how this would work. Basically, the idea is
that Forrest provides the default configuration in its LM, individual
projects can then override these settings in their own LM.
For example, we currently have:
<map:parameter name="config-file" value="{project:skinconf}"/>
Where project:skinconf is set in forrest.xconf (via forrest.properties).
With my current work on the LM we will have:
<map:parameter name="config-file" value="{lm:project.skinconf}"/>
where lm:project.skinconf is set in locationmap.xml.
In this first stage we still use {project:skinconf} in the LM, so we
gain nothing. However, in the next stage I intend to replace this with
the actual path (i.e. what is currently in default-forrest.properties
If a project wants to change the location of the skinconf file they can
do so in the LM rather than in forrest.properties. Thus, a change does
not require a server restart.
What is missing?
================
Multiple Sites
--------------
Forrest needs to be able to host multiple sites, each with their own
configuration. We need to extend the locationmap mounting code to allow
a specific project file to be mounted. This will be dependant on the
request. Since the LM has access to the request object, this shouldn't
be too hard to do.
None Location configuration
---------------------------
Some configuration has nothing to do with file location, for example,
the name of the theme to use. We need to consider where this
configuration will go. I've not thought hard about this issue yet, but
my guts tell me that *all* parameters are only inportant to Forrest with
respect to a location, for example, the project.theme value is used to
build a path to retrieve theme related files.
If my guts are correct, we need to allow the locatonmap to have a
variables section. These variables can then be used later in the locator
to define a path.
Even if my guts are incorrect, I think we still need this variable
feature since some paths will appear in multiple locators (i.e.
content/documentation)
Thoughts?
Ross
