I'm wondering why the ComponentDefinitions interface has been exposed
outside of the DefinitionsFactory. To me, this class seems like an
implementation detail of the factory itself, and it should not be exposed.
Currently the interface is only used in three points outside of the
DefinitionsFactory (besides in tests):
1) TilesFilter - used for refreshing the component definitions
2) TilesUtilImpl - used to share the instance with the world
3) ComponentDefinition - used to resolve hierarchy
I don't think any of these require the component definitions. I'd like
to discuss refactoring them in the following manner:
1) Encapsulate the refresh logic in the DefinitionsFactory. The filter
will change to:
if(factory.refreshRequired()) {
// replace refresh logic with a call
// to the factory, removing the reference
// to ComponentDefinitions
factory.refresh();
}
2) TilesUtilImpl only exposes the ComponentDefinitions in order to allow
the Filter (#1) to access them. This reference can easily be removed.
3) Encapsulate the hierarchy resolution within the DefinitionsFactory,
allowing the resolution to occur during initialization.
I believe that this refactor will remove some complexity and the
cyclical dependency which has been created between the
DefinitionsFactory and it's runtime environment. IMHO, the
DefinitionsFactory should only be concerned with creating
ComponentDefinition objects, it should not need to know anything about
it's outside environment (see the current call to the Application Scope
map in order to re-retrieve the ComponentDefinitions).
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
