forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [Discuss] Refactoring of ForrestConfModule
Date Thu, 10 Aug 2006 00:21:49 GMT
Hi all,

current work and the thread revealed some
issues with our current usage of the forrestConfModule.

We use it two times in the forrest-core.xconf with two different names
"defaults" and "projects" as prefix. ForrestConfModule does not
implement configure(...) meaning it will use the one from super
(DefaultsModule). This is adding properties from the configuration
(which are different for defaults vs. project).

The new org.apache.forrest.plugin.output.inputModule plugin produces
properties from an input-module.
shows an example of my setting building the plugins docs. This are exactly the <values>
from the defaults xconf configuration. 

will as well shows exactly the values defined in the xconf. 

However since we look up a lot more properties via looking up different
configuration files the expected behavior would be to return an Iterator
based on Enumeration enumeration =filteringProperties.keys();

This can be done by implementing 
public Iterator getAttributeNames( Configuration modeConf, Map
objectModel ). 

Something like the following:
public Iterator getAttributeNames( Configuration modeConf, Map
objectModel ) 
    throws ConfigurationException {
    	SortedSet matchset = new TreeSet();
        Enumeration enumeration =filteringProperties.keys();
        while (enumeration.hasMoreElements()) {
            String key = (String) enumeration.nextElement();
        Iterator iterator =
        while (iterator.hasNext())
        return matchset.iterator();

The above iterator will return now for the
properties of the xconf + the ones coming from other properties files. 

The above iterator will return now for the
properties of the xconf + the ones coming from other properties files. I added there some
sample files. New is with the iterator, old using super.

Implementing the Iterator will close FOR-800 and reveals the problem I
see with the current situation, you can use (right now without any
changes applied):
<map:transform src="foo.xsl">
 <map:parameter name="defaults" value="{defaults:dispatcher.theme}" />
 <map:parameter name="project" value="{project:dispatcher.theme}" />

With foo.xsl having:
  <xsl:param name="defaults"/>
  <xsl:param name="project"/>
  <xsl:template match="/">
    defaults: <xsl:value-of select="$defaults"/>; project: <xsl:value-of

and it returns
defaults: pelt; project: pelt;

I think it is not good to have two different component-instance that

- for some calls like {defaults/project:dispatcher.theme} the same 

- for other different 
   {defaults:home} - ~/src/apache/forrest/trunk/
   {project:home}  -

- and for some causing an error
   {defaults:i18n} - false
   {project:i18n} - error: Unable to get attribute value for i18n

That is way too confusing and error causing for me.

If we still need the defaults module then this should be done with a
slim downed version of the ForrestConfModule. Actually I tried with 
<component-instance name="defaults"
class="org.apache.cocoon.components.modules.input.DefaultsModule"> but 
/home/thorsten/src/apache/forrest/trunk/main/webapp/@context.home@/locationmap.xml (No such
file or directory)

Meaning we "only" have to extend the DefaultsModule with the possibility
to resolve @context.home@ etc. on...

I am not even sure whether we need the defaults instance at all. We can
just use prefixed key aka forrest.home to identify core properties and
only use the project instance. We already started to double define
variable like 
{project:forrest.home} = {defaults:home}, so I think it is best to merge
both modules and support only {project:forrest.home} or maybe renamed
like {properties:forrest.home}

I think we should merge the modules ASAP.



"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message