ChainMetaModule quirk (possible rewrite?)

[Grzegorz Kossakowski <gr...@tuffmail.com>]

Hello,

I'm still working on refactoring Forms and Ajax. Following Daniel's
advice[1] I try to configure LinkRewriterTransformer for needs of
rewriting servlet: links to the resources. I need use ChainMetaModule,
because it has concatation feature (<all-values> configuration option).
Sadly, I've encountered its quirk, take a look at getAttribute method:
    public Object getAttribute( String attr, Configuration modeConf, Map
objectModel )
    throws ConfigurationException {
        Object[] values =
this.getAttributeValues(attr,modeConf,objectModel);
        if (getLogger().isDebugEnabled()) getLogger().debug("result
chaining single for "+attr+" is "+(values != null? values[0] : "null"));
        return (values != null? values[0] : null);
    }

In order to get one value it scans through all modules listing all
possible values! Not only this is inefficient but also narrows possible
usage. Block-path module obviously does not support listing all values
because list would be endless. Given this, ChainMetaModule is useless in
this case.

I would like to ask few questions:
1. Does anyone know why ChainMetaModule behaves the way described above?
2. Would you be happy if I rewritten it from scratch with
back-compatibility in mind?
3. If so, would be happy if I used Java 1.5 features?

Or do you have better options?

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/69931
[2]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-components/src/main/java/org/apache/cocoon/components/modules/input/ChainMetaModule.java?view=markup

-- 
Grzegorz Kossakowski

Re: ChainMetaModule quirk (possible rewrite?)

[Grzegorz Kossakowski <gr...@tuffmail.com>]

Daniel Fagerstrom napisał(a):
>> 2. Would you be happy if I rewritten it from scratch with
>> back-compatibility in mind?
>
> Yes.

I've done it already, but assumed that answer to the point three will be
"yes". My bad, but I'll try to adjust the code to the Java 1.4.
>
>> 3. If so, would be happy if I used Java 1.5 features?
>
> No, Cocoon 2.2 is supposed to work with Java 1.4. We had a vote about
> it some while ago.

Ok, I'll live with it somehow...
>
>> Or do you have better options?
>
> Maybe it would be a better idea to write a special purpose link
> rewriter for the block protocol. Where you only configure what
> attributes to rewrite. Looking at the code for the link rewriting
> transformer, the actual work is just a few rows. Most of it is about
> handling all the bewildering amount of configuration options.
Too late ;-)
I've just successfully configured standard LinkRewriteTransformer. I've
had to write my own input module for string concatation, though. Is
there any obvious benefit of writing our own transformer?
cocoon-linkrewriter-impl block has no additional dependencies,
configuration of it is clean and straightforward, finally, user does not
have to configure it in its sitemaps again and agin. Wait with your
response until I polish and submit the code I already have.

-- 
Grzegorz Kossakowski

Re: ChainMetaModule quirk (possible rewrite?)

[Daniel Fagerstrom <da...@nada.kth.se>]

Grzegorz Kossakowski skrev:
> Hello,
> 
> I'm still working on refactoring Forms and Ajax. Following Daniel's
> advice[1] I try to configure LinkRewriterTransformer for needs of
> rewriting servlet: links to the resources. I need use ChainMetaModule,
> because it has concatation feature (<all-values> configuration option).
> Sadly, I've encountered its quirk, take a look at getAttribute method:
>     public Object getAttribute( String attr, Configuration modeConf, Map
> objectModel )
>     throws ConfigurationException {
>         Object[] values =
> this.getAttributeValues(attr,modeConf,objectModel);
>         if (getLogger().isDebugEnabled()) getLogger().debug("result
> chaining single for "+attr+" is "+(values != null? values[0] : "null"));
>         return (values != null? values[0] : null);
>     }
> 
> In order to get one value it scans through all modules listing all
> possible values! Not only this is inefficient but also narrows possible
> usage. Block-path module obviously does not support listing all values
> because list would be endless. Given this, ChainMetaModule is useless in
> this case.
> 
> I would like to ask few questions:
> 1. Does anyone know why ChainMetaModule behaves the way described above?

No idea.

> 2. Would you be happy if I rewritten it from scratch with
> back-compatibility in mind?

Yes.

> 3. If so, would be happy if I used Java 1.5 features?

No, Cocoon 2.2 is supposed to work with Java 1.4. We had a vote about it 
some while ago.

> Or do you have better options?

Maybe it would be a better idea to write a special purpose link rewriter 
for the block protocol. Where you only configure what attributes to 
rewrite. Looking at the code for the link rewriting transformer, the 
actual work is just a few rows. Most of it is about handling all the 
bewildering amount of configuration options.

/Daniel

Re: ChainMetaModule quirk (possible rewrite?)

[Grzegorz Kossakowski <gr...@tuffmail.com>]

Grzegorz Kossakowski napisał(a):
> Hello,
>
> I'm still working on refactoring Forms and Ajax. Following Daniel's
> advice[1] I try to configure LinkRewriterTransformer for needs of
> rewriting servlet: links to the resources. I need use ChainMetaModule,
> because it has concatation feature (<all-values> configuration option).
> Sadly, I've encountered its quirk, take a look at getAttribute method:
>     public Object getAttribute( String attr, Configuration modeConf, Map
> objectModel )
>     throws ConfigurationException {
>         Object[] values =
> this.getAttributeValues(attr,modeConf,objectModel);
>         if (getLogger().isDebugEnabled()) getLogger().debug("result
> chaining single for "+attr+" is "+(values != null? values[0] : "null"));
>         return (values != null? values[0] : null);
>     }
>   
Even more misleading is the documentation of this modules :(
Take a look at this[1]:

Configuration:

It can be controlled whether it returns a flat or a deep view, i.e.
whether only values from the first module are returned if non-null or
they are merged with values from other modules
|<all-values>true</all-values>|. The same is possible for the attribute
names (|<all-names/>|). In addition, empty strings could be treated the
same as null values (|<empty-as-null/>|).

Do I get it that if all-values is true getAttribute should return list
of values of configured modules, exactly one value per configured input
module? And then getAttributes should just merge attributes from all
configured input modules. However, looking at the snippet above it's
clear no of situations described take place!
I've got enough confidence to rewrite it...

-- 
Grzegorz Kossakowski