I don't see these factory implementations changing much. Instead, what
will change is how tiles interfaces with surrounding frameworks.
Specifically how it is:
1) Configured/Initialized
2) Invoked
3) Destroyed
By surrounding frameworks.
Instead of utilizing a series of static invocations, what I envision is
a container being instantiated and initialized. When ever the framework
needs to invoke it, it will retrieve it - probably from a static cache
that it maintains or from the servlet context - and will invoke instance
methods.
What this does is create a "container" environment in which frameworks
can "inject" custom implementations of the different Factories/Service.
By taking this approach, I think it will be easier to support this
level of customization. We will also avoid the common classloader issue
which we briefly mentioned and thus be able to support multiple
application contexts if necessary (even though we decided it's not).
David
Antonio Petrelli wrote:
Greg Reddin ha scritto:
On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote:
I'll probably have some time to finish up the TilesContextFactory
configuration today and start doing some work on removing
duplication. Once I get through that I'll start putting some
container ideas down into code. The first step of that process will
be to define the tiles container api. What are those things that we
want to expose to the world?
... Antonio may have more input since he's working with some Tiles
extensions.
The "extension" that Greg was writing about is Dimensions:
http://mutidimensions.sf.net/
In the HEAD of the CVS repository I am trying to port Dimensions to
Tiles 2. Although it is not updated to the latest changes it could be
helpful. In my case I created:
* a class (KeyedComponentDefinitionsImpl) that extends
ComponentDefinitionsImpl, allowing to store Tiles definition in a
different manner (it uses the user's role and the calling device,
besides locale, to store specific definitions);
* a pair of classes (ChannelDefinitionsFactory and
ConfigurableDefinitionsFactory) that extend UrlDefinitionsFactory, that
interpret the HTTP request and return the correct definition, using
KeyedComponentDefinitionsImpl for the storage.
How does your "container" fit in?
HTH
Antonio
---------------------------------------------------------------------
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]
