Ship generic generator with Cocoon?

[Peter Hunsberger <pe...@gmail.com>]

Looking at our generators it seems to me that it shoudl be possible to
build a general purpose generator that works for many data sources
right out of the box.  In Pseudo code it would look more or less like:

private DataSource source = null;

public void setup (SourceResolver res, Map om, String src, Parameters
par) throws... {
    source = resolve( res, om, src, par );
    if ( !source instanceof XMLizable ) throw  BadSourceException...
    if ( source instance of AuthenticableSource ) {
        AuthManager.auth( source, om, par );  // may throw not authorized
    }
}

public resolve(  SourceResolver res, Map om, String src, Parameters
par) throws ... // NoSourceAvailableException type stuff
  return res.resolve( src );  // Is some factory needed here?
}

public Serializable getKey() {
    if ( !source instanceof CacheableSource )
        return null;
    return source.getKey();
}

public SourceValidity getValidity() {
    if ( !source instanceof CacheableSource )
        return null;
    return CacheManager.getValidity( source );
}

public void generate( ) throws  .... {
    xmlConsumer.startDocument();
    source.toSax( xmlConsumer );
    xmlConsumer.endDocument();
    if ( source instanceof CacheableSource )
        CacheManager.setValidity( source, new DefaultSourceValidity() );
}
       
For our purposes I also need an additional source type to be used when
resolving the source so we'd override the resolve method to provide
our own implementation of resolve but that's pretty much it. (I
haven't played much with SourceResolvers thus I'm not sure exactly how
that needs to work...)  I'm guessing you could provide pluggable
source resolvers via a configuration param, or is there some other way
to specify the resolver via the sitemap on a per instance of the
generator basis?  If so then there's no need to have the ability to
override this method and it goes away.

I also don't know exactly what the default AuthManager might look like
for the generic case? The ability to set alternatives would be a
configuration parameter.  Basic idea here is that likely some user
authentication key will be stashed in Session, but by passing the
entire object model you can get fancier if needed.  We have something
that meets our needs, but if there is a generic model/interface we can
implement then something can ship out of the box.

The cache manager would just create the mapping of the source key to a
place holder validity. The cache manager provides additional methods
for the action side of the world to use to invalidate the validity
using the same key (via a source if desired).  Again the validity type
to use should be a configuration parameter.

Arguably the ability of the source to generate it's own key isn't a
good seperation of concerns but personally I think it's ok:  basically
this means that any given source has to have some way of being
constructed/initialized so that even if it is not complete it can at
least respond back to a getKey() request.  We use this pattern in our
code and it works well.

It seems to me that most of the pieces are already present in Cocoon.  
Anyone have any specific comments on things I should look at or
anything I might be missing?

-- 
Peter Hunsberger