forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Processing properties in Forrest core (was Re: svn commit: r355634 - /forrest/trunk/site-author/
Date Mon, 12 Dec 2005 13:17:25 GMT
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, escribió:
>>>>Author: rgardler
>>>>Date: Fri Dec  9 15:07:30 2005
>>>>New Revision: 355634
>>>>no longer need as plugin will now provide defaults
- only need this if you want behaviour other than the default
>>>>   forrest/trunk/site-author/
>>>How can I request all available properties (default and specific)?
>>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/ (experimental)
>>- PROJECT_HOME/ (may be deprecated)
>>- PLUGIN_HOME/ (experimental)
>>   - iterate over all active plugins
>>- FORREST_HOME/ (experimental)
>>- FORREST_HOME/ (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:
>>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. 


> 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.


> salu2 

View raw message