Greg Reddin wrote:
On Oct 21, 2006, at 10:02 PM, David H. DeWolf wrote:
The one negative to this approach is that it will eliminate the
ability to support multiple contexts (when tiles is packaged in a
common classloader). The TilesUtil currently appears to be
implemented in a way which suggests that the original intent was to
support multiple contexts. That said, the support is already only
partial since Tiles utilizes several static accessors and instances
such as TilesUtilImpl will be shared across applications.
I don't personally want to go to great lengths to support running Tiles
in a common classloader. If it happens to work then fine. But I would
not call it a best practice. Maybe there's situations where it is
warranted, but I haven't personally encountered those.
Agreed.
The second approach that would solve this issue would be to refactor
the codebase to eliminate the prevalent use of static methods.
Instead, all tiles functionality could be configured and encapsulated
into a self contained "container" which would be cached and retrieved
when needed.
I'm definitely in favor of this approach. I have no problem with static
methods but, as Antonio has pointed out, it makes things more difficult
to configure. I'm having a similar issue with MyFaces Tomahawk
components where I'd like to modify a renderer but the modification is
in a non-configurable static utility class. Also, caching objects as
static members of utility classes in a multi-threaded environment is
problematic at best. So, I'm definitely in favor of this aspect.
Ok, good to know.
In this scenario, the configuration servlet, filter, or listener,
would create the container and provide access to it from a publicly
available place (perhaps the underlying context). Whenever tiles were
needed, the client would retrieve the container and invoke it.
Services like the TilesUtil would be provided by the container, not
statically accessed.
I like this approach. Since this is the place where other frameworks
will have the most interaction with Tiles we should try to make it as
straightforward as possible. This kinda goes along with SB-56 [1] that
you opened doesn't it?
To a degree yes. SB-56 speaks to removing the duplication of
initialization logic. Encapsulating all tiles functionality into a
container would definitely promote/help that, but I can also imagine
ways to remove the duplication which don't promote the componantization
we're looking for from a container approach (e.g. create more static
utilities to do the initialization).
As moving in this direction is quite a large undertaking from it's
current state, my suggestion is that we complete it in steps - the first
of which is probably completing the TilesContextFactory configuration
using the current TilesUtil implementation. From there we can start
removing duplication and componentizing/containerizing tiles.
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?
Do we prefer to do the container work in a branch, or continue working
on it in the trunk?
David
Greg
[1] https://issues.apache.org/struts/browse/SB-56
---------------------------------------------------------------------
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]
