You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "David H. DeWolf" <dd...@apache.org> on 2006/10/31 22:10:05 UTC
[tiles2] ComponentDefinitions - exposed implementation detail?
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
Posted by "David H. DeWolf" <dd...@apache.org>.
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:
Yes, I agree that we don't want the factory to do too much. That said,
it's already responsible for a lot (creation, caching, locale
resolution, etc. . .). I think that it's really more a manager and
perhaps we're getting caught up in semantics. It already delegates to
the reader for the actual parsing.
>
>> 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.
It's probably ideal to have a Manager of some sort that encapsulates the
caching and refresh logic and delegates to the factory for the actual
"creation" operations. If that's what you're thinking in the back of
your head, I'm on board with it.
The one complexity there is that the refresh logic actually requires a
bit of low level operations that the factory should only be aware of
(specifically, opening the URLConnection). Because of that, I'd tend to
leave the actual refresh determination in the factory, but move the
caching and management of the actual entities up a level.
>
>> 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.
I'm thinking that the container literally exposes a few methods as
simple as:
void render(Object request, Object response, String preparer)
That way, clients (and hopefully even our tags) loose a lot of knowledge
about the ComponentDefinitions. Under the covers, the Container will
maintain the ComponentDefinitions and worry about the lifecylce of
invocation (meaning, 1) creating the component context, 2) invoking the
preparer, 3) invoking the definitions, etc. . .)
>
>> 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.
Gotcha!
In fact, I didn't mean to imply that we would dump it all in the
factory. Instead, I was thinking incrementally. My first step was to
remove the Factory's knowledge of it's outside world by not publishing
the ComponentDefinitions. I thought that would entail two steps -
having the Filter invoke the factory to do the refresh logic and
resolving inheritance differently. As Antonio pointed out, the
inheritance references in the ComponentDefinition aren't even used
anymore so the change actually turns out to be even simpler.
Since it seems as though we all agree on this first step, why don't we
move forward with it and then I'll take a deeper look into a larger
refactoring.
>
> 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.
Sounds like a plan.
David
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
>
>
> Antonio Petrelli wrote:
>> David H. DeWolf ha scritto:
>>> 3 DefinitionsManager - cache definitions, resolve dependencies,
>>> manage localization.
>>
>> It seems that it is ComponentDefinitions renamed. Or not?
>
> ... I do think that:
>
> 1) caching
> 2) inheritence resolution
>
> should be moved outside of the factory so that those features can be
> reused by components that are not "created" by the factory.
Speaking of inheritance resolution, Dimensions uses a configurable
"inheritance resolver" to resolve inheritances between multiple files.
Maybe it could help you, Dimensions is licensed under ASL 2.0 so you
should not have any problem in copying some code :-)
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> David H. DeWolf ha scritto:
>> 3 DefinitionsManager - cache definitions, resolve dependencies, manage
>> localization.
>
> It seems that it is ComponentDefinitions renamed. Or not?
Well, I almost went there, but I don't think it is. The difference is
that currently ComponentDefinitions is an implementation detail of the
factory. While I don't have a problem if it remains one, I do think that:
1) caching
2) inheritence resolution
should be moved outside of the factory so that those features can be
reused by components that are not "created" by the factory.
>
>> 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.
>
> There was a similar feature in Struts-Tiles, called FactorySet, that
> linked one DefinitionsFactory to a key and supporting multiple keys.
> Dimensions for Struts-Tiles leverages this feature, while Dimensions for
> Tiles 2 uses only DefinitionsFactory.
> In particular, Dimensions uses a hierarchical default levels, e.g. if
> you have a Sony WAP phone (this is not an advertisment), first it tries
> to use definitions for your phone, if it does not find it, it tries with
> WAP phone, then it tries to default to base definitions.
> What I am trying to say is that default may be more complex than you may
> think, one default may be not enough.
Agreed. I was just trying to pick a simple example :)
David
>
> Ciao
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> 3 DefinitionsManager - cache definitions, resolve dependencies, manage
> localization.
It seems that it is ComponentDefinitions renamed. Or not?
> 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.
There was a similar feature in Struts-Tiles, called FactorySet, that
linked one DefinitionsFactory to a key and supporting multiple keys.
Dimensions for Struts-Tiles leverages this feature, while Dimensions for
Tiles 2 uses only DefinitionsFactory.
In particular, Dimensions uses a hierarchical default levels, e.g. if
you have a Sony WAP phone (this is not an advertisment), first it tries
to use definitions for your phone, if it does not find it, it tries with
WAP phone, then it tries to default to base definitions.
What I am trying to say is that default may be more complex than you may
think, one default may be not enough.
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
Posted by Greg Reddin <gr...@apache.org>.
On Nov 6, 2006, at 7:07 AM, David H. DeWolf wrote:
> 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.
I like this approach. I think it cleans up the interface and makes
responsibilities more cohesive.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
Posted by "David H. DeWolf" <dd...@apache.org>.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
Posted by Greg Reddin <gr...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> . . .
> So you are suggesting to put almost all the ComponentDefinitionsImpl
> code inside UrlDefinitionsFactory? It is fine with me, but I don't know
> what does Greg think of it :-)
> . . .
No, not necessarily. For now I was just going to make it a private
member and ensure that it's not exposed externally. That definitely may
well be the next step though, I just hadn't thought of it yet ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> 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.
Notice that before I committed SB-28 DefinitionsFactory class did not
have a "getDefinition" method at all. Before this change, only
ComponentDefinitions could return a ComponentDefinition.
Anyway, I think I agree with you, ComponentDefinitions is a way to store
definitions, and its implementation is tightly connected to the
DefinitionsFactory implementation.
Probably before the change (SB-28 again) ComponentDefinitions had some
sense to exist, but at this point I think it is only one more layer.
But before cutting off ComponentDefinitions I think we should wait Greg
that can explain better the role of ComponentDefinitions, probably
ComponentDefinitions is the last class where the Locale object is part
of the main API, since it has been removed from DefinitionsFactory by me...
>> 3) ComponentDefinition - used to resolve hierarchy
In fact the methods that use ComponentDefinitions in ComponentDefinition
are deprecated (and never used), I think they can be removed.
>> 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();
>> }
Yeah much better!
>> 2) TilesUtilImpl only exposes the ComponentDefinitions in order to
>> allow the Filter (#1) to access them. This reference can easily be
>> removed.
It's almost the change that I did in SB-28, I agree completely.
>> 3) Encapsulate the hierarchy resolution within the
>> DefinitionsFactory, allowing the resolution to occur during
>> initialization.
This will happen only with the default Tiles configuration files. With
locale-specific files it will happen when a certain Locale is being used.
>> 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).
So you are suggesting to put almost all the ComponentDefinitionsImpl
code inside UrlDefinitionsFactory? It is fine with me, but I don't know
what does Greg think of it :-)
> By the way, Antonio, I've looked at multidimensions at a high level,
> and realize that you're providing a unique implementation of this
> interface. I meant to mention that I believe that you could
> accomplish the same thing (if we were to perform the refactor
> suggested below), by providing a customized DefinitionsFactory (that
> probably extends the UrlDefinitions factory).
Yes, extending one class is better that two :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
Posted by "David H. DeWolf" <dd...@apache.org>.
By the way, Antonio, I've looked at multidimensions at a high level, and
realize that you're providing a unique implementation of this interface.
I meant to mention that I believe that you could accomplish the same
thing (if we were to perform the refactor suggested below), by providing
a customized DefinitionsFactory (that probably extends the
UrlDefinitions factory).
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.
>
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org