Thorsten Scherler wrote:
El lun, 12-12-2005 a las 11:15 +0000, Ross Gardler escribió:
Thorsten Scherler wrote:
El vie, 09-12-2005 a las 23:07 +0000, [EMAIL PROTECTED] escribió:
Author: rgardler
Date: Fri Dec 9 15:07:30 2005
New Revision: 355634
URL: http://svn.apache.org/viewcvs?rev=355634&view=rev
Log:
no longer need forrest.properties.xml as plugin will now provide defaults -
only need this if you want behaviour other than the default
Removed:
forrest/trunk/site-author/forrest.properties.xml
How can I request all available properties (default and specific)?
cocoon://¿?
Right now you can't get the various values. There is only one property
recorded - the one to actually use. The defaults are not recorded,
unless they are the ones to use.
However, this can be changed.
The processing of the properties is done in [1]
The first value for a given property is the one we record, so we load
the various config files in the following order:
- PROJECT_HOME/forrest.properties.xml (experimental)
- PROJECT_HOME/forrest.properties (may be deprecated)
- PLUGIN_HOME/default.plugin.properties.xml (experimental)
- iterate over all active plugins
- FORREST_HOME/default.forrest.properties.xml (experimental)
- FORREST_HOME/default.forrest.properties (may be deprecated)
What you could do is modify [1] to record each of those files in a
separate properties collection and provide a special property request
for getting a default value.
For example:
{forrest:default.PROPERTYNAME}
would give the default rather than the user supplied one. To enable this
all you would have to do is modify getAttribute(...) in [1] to detect
this special request and process accordingly.
If you do this we need to make this part of the naming convention so
that no property can start with the word "default". There is no
documentation for this system yet, but I am tracking things via [2]
Please be sure to include this issue number in any commits and add notes
to the documentation task associated with that issue.
Hmm, with other words the properties are store in an input module. What
I was looking for is an aggregation of the above properties but not in
an module but as plain xml.
OK
What do you thing what makes more sense, write some custom generator
that would contact the input module and generate SAX events from the
properties or simply aggregate them in the sitemap?
I'd go for the generator approach, more efficient which is important
given that there may be a large number of separate config files.
In addition, this will access t none-XML properties during the
(possible) migration to the XML system.
Ross
salu2
Ross
[1]
http://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest/conf/ForrestConfModule.java
[2] http://issues.apache.org/jira/browse/FOR-739
