[Discuss] Refactoring of ForrestConfModule

[Thorsten Scherler <th...@apache.org>]

Hi all,

current work and the thread
http://marc.theaimsgroup.com/?t=115493806000005&r=1&w=2 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.
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.inputModule/module.defaults.properties shows an example of my setting building the plugins docs. This are exactly the <values> from the defaults xconf configuration. 

Requesting
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.output.inputModule/module.project.properties 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();
            matchset.add(key);
        }
        Iterator iterator =
super.getAttributeNames(modeConf,objectModel);
        while (iterator.hasNext())
            matchset.add(iterator.next());
        return matchset.iterator();
 }

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

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

http://people.apache.org/~thorsten/whiteboard/conf/ 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}" />
</map:transform>

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
select="$project"/>;
  </xsl:template>

and it returns
defaults: pelt; project: pelt;

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

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

- for other different 
   {defaults:home} - ~/src/apache/forrest/trunk/
   {project:home}  -
~/src/apache/forrest/trunk/plugins/org.apache.forrest.plugin.output.inputModule

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

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

wdyt?

salu2
-- 
thorsten

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

Re: [Discuss] Refactoring of ForrestConfModule

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> I think we should merge the modules ASAP.
> 
> wdyt?

My response to this one is short and sweet...

Go for it!

Ross