[T5] ComponentClassResolver should expose it's configuration

[Ognen Ivanovski <og...@netcetera.com.mk>]

Hi again,

I think that the ComponentClassResolver should expose it's  
configuration via the service interface; i.e. it should say which  
packages are library packages. Of course this configuration should be  
immutable.

public List<LibraryMapping> getLibraryMappings();

The need for this can be illustrated by the tapestry-hibernate  
module. In HibernateModule we see that the HibernateSessionSource  
service accepts a configuration of packages that should be searched  
for entities.

So in the module we have:

     /**
      * Contributes the package "&lt;root&gt;.entities" to the  
configuration, so that it will be
      * scanned for annotated entity classes.
      */
     public static void contributeHibernateSessionSource 
(Configuration<String> configuration,

     @Inject
     @Symbol(InternalConstants.TAPESTRY_APP_PACKAGE_PARAM)
     String appRootPackage)
     {
         configuration.add(appRootPackage + ".entities");
     }

Which adds the application standard entity package to the sessions  
source configuration. Now, this is ok for single module applications.  
When you have an application that is composed of several sub-apps, in  
each of them you have to contribute

     public void contributeComponentClassResolver 
(Configuration<LibraryMapping> conf)
     {
         conf.add(new LibraryMapping("subapp1", "com.example.subapp1");
     }

     public void contributeHibernateSessionSource 
(Configuration<String> configuration)
     {
         configuration.add("com.example.subapp1.entities");
     }

This is not so DRY. I'm also developing a service that adds type  
coercions for all entities. It too needs to scan the entity packages  
so it too must be configured with a package. Then I have a navigation  
service + component that builds up a navigation tree by scanning for  
pages that have a @Navigable annotation. it too needs to receive yet  
the same packages as configuration so it can scan. So in each sub-app  
module I have 4 different contribution method contribution more or  
less the same information on different places.

But if the ComponentClassResolver would expose the library mappings  
then I would have something like:

     public static void contributeHibernateSessionSource(
	@Inject componentClassResolver componentClassResolver,
	Configuration<String> configuration
)
     {
	for (LibraryMapping lib : componentClassResolver.getLibraryMappings 
()) {
           configuration.add(lib.getRootPackage() + ".entities");
	}
     }

So all these services (hibernate source, navigation service,  
hibernate entity coercer) will be able to automatically configure  
themselves and the modules would need (again) only to specify library  
mappings to the component class resolver.

What do you think?

Cheers,
Ognen
--
Ognen Ivanovski | ognen.ivanovski [at] netcetera.com.mk
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org