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/26 15:03:43 UTC
[tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
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: 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] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> I don't see these factory implementations changing much.
> ...
You've been very clear, thank you :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by "David H. DeWolf" <dd...@apache.org>.
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: 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] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by Antonio Petrelli <ap...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory refactor)
Posted by Greg Reddin <gr...@apache.org>.
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?
It doesn't seem like much. The majority of what people will do with
Tiles is plug it into another architecture, so we need to focus on
the points where it interfaces with MVC architectures I think.
Beyond that, there will be cases where people want to create, modify,
and access definitions and attributes. I'd say keep the public API
as small as possible and add to it as requests come in. Antonio may
have more input since he's working with some Tiles extensions.
> Do we prefer to do the container work in a branch, or continue
> working on it in the trunk?
Either way is fine with me. I would prefer to just do it in the
trunk since it can be done incrementally.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org