I wanted to back up as Greg suggested in regards to the role of the
DefinitionsFactory and ComponentDefinitions within the TilesContainer.
As I've removed the static factories and created the new container
environment, I left these two components alone (except for removing the
publication of the definitions to the filter).
Currently, only two core pieces of functionality are unimplemented in
the container "refactoring". Both of these (the definition and
initDefinitions
tags), are unique in the fact that they manipulate the state of the
container, while all others simply request something from the container
(a render operation or a list of current attributes).
To level set, here is what I have been driving towards and think we
should continue to focus on as we consider the DefinitionsFactory and
ComponentDefinitions:
1) develop a simple facade (container). The facade should encapsulate
all tiles processing and implementation details and be used both by our
own interfaces (tags) and those (integration points) developed by
integrating frameworks.
2) create a componentized framework which allows key pieces to be easily
replaced by providing new implementations of standard interfaces.
3) Clean, simple design which clearly separates concerns.
Currently, I believe (feel free to disagree), that for the most part
we've accomplished this while implementing the container. The current
implementation of the definitions factory however, remains in question.
It seems to me as though the responsibilities are a little blurred.
Here is how I see the current state:
1) DefinitionsFactory - responsible for the management and retrieval of
definitions (i.e. invoking the reader when appropriate, choosing the
correct definition for a given request, etc. . .).
2) DefinitionsReader - responsible for parsing the input stream into a
map of ComponentDefinitions
3) ComponentDefinitions - used by the container to cache definitions and
resolve inheritance.
4) If you were to consider these components the definitions service, the
factory would be the interface to the outside world.
The reader's responsibility is clear and I think it should remain that
same. The relationship between the Factory, the ComponentDefinitions,
and the rest of the tiles system seems a little awkward/backwards to me.
Here is what I envision:
1) DefinitionsReader - parse an input stream into a map of definitions.
2) DefinitionsFactory - manage the creation of definitions. instantiate
the appropriate readers, manage refreshes.
3 DefinitionsManager - cache definitions, resolve dependencies, manage
localization.
This allows us to pull the caching of definitions outsite the factory
and releave it of that responsibility. By doing so, it's only
responsible for the creation/management of definitions which it creates
in the firstplace, and the manager is responsible for pulling all of the
definitions together into a single location.
The benefit of this is:
1) Allows us to support more than one factory - if we decide to down the
road that it would be beneficial. A use case for this may be a system
which provides defaults in the tiles-defs.xml and allows users to create
other definitions through the interface which are subsequently stored in
the database.
2) Allows us to easily add definitions which are created externally
through a simple container api:
TilesContainer:
--------------------
void addDefinition(String name, String template, String role, Map
attributes) {
ComponentDefinition def = . . .
definitionsManager.register(name, def);
}
Thoughts?
David
Greg Reddin wrote:
On Oct 31, 2006, at 3:10 PM, David H. DeWolf wrote:
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.
If you look back at Tiles 1 you'll see that DefinitionsFactory and its
descendants pretty much contained all of the functionality that we've
separated into DefintionsFactory and ComponentDefinitions. It was both
a factory and a container if you will. This was especially true if you
drilled down into xmlDefinitions and the classes under that. A lot of
core Tiles functionality was embedded deep into the XML version of the
implementation and not exposed on the API.
Let's keep in mind the value of separation of concerns. I don't think
we want the factory to do too much. Remember what the purpose of a
factory is - to create objects and nothing more. I think anything
beyond the creation and storage of definitions should be delegated
outside the factory so that if someone wants to override the creation
and storage functionality, but wants to keep other pieces in place they
can do that. See further comments below:
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();
}
I'm OK with this because it still seems related to "factory" like code
to me. The factory is being used for manufacturing and repair in this
case :-) That doesn't bother me.
2) TilesUtilImpl only exposes the ComponentDefinitions in order to
allow the Filter (#1) to access them. This reference can easily be
removed.
This is true, but TilesUtilImpl is likely going to be replaced by our
container API. So maybe the container API replaces
ComponentDefinitions. That's really what ComponentDefinitions was
created for - to separate container logic from creation logic. So, if
the container exposes everything that's currently being taken care of by
ComponentDefinitions I'm cool with it. But, again, I want to avoid a
monolithic API that does too much. We need to find the sweet spot of
APIs that are small and manageable, but yet complete.
3) Encapsulate the hierarchy resolution within the DefinitionsFactory,
allowing the resolution to occur during initialization.
Looking at ComponentDefinitions right now, it provides APIs to add
definitions, get definitions, and resolve inheritances (and some
ancillary things that might just be side effects). DefinitionsFactory
has APIs to get and read definitions. There's some overlap, redundancy,
and perhaps misplaced responsibilities. I do think we need to rethink
some things, but I'm not convinced that dumping it all into the factory
is the right thing to do.
Maybe we can back up a bit, identify the core responsibilities, and
decide where each one fits between the factory, the container, and
whatever else.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
