struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <>
Subject [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory refactor)
Date Thu, 26 Oct 2006 13:03:43 GMT

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.


>> 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?


> Greg
> [1]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message