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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
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, wh
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.
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 th
On 10/25/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
Greg Reddin wrote:
>
> On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
>
>> Now the question is: Why do you need multiple
>> TilesApplicationContexts? Just curious :-)
>
> I think David was asking the same question. If Tiles is depl
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 s
Greg Reddin wrote:
On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
Now the question is: Why do you need multiple
TilesApplicationContexts? Just curious :-)
I think David was asking the same question. If Tiles is deployed in a
common classloader (i.e. Tomcat's common/lib directory) y
On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
David H. DeWolf ha scritto:
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 w
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 or
David H. DeWolf ha scritto:
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
Hmm, I forgot something until I went to implement this approach. . .
It will be nearly impossible to avoid accessing the
TilesApplicationContext in order to create the TilesRequestContext
unless we change a couple of things. The reason is that we currently
provide access to factories through
Greg Reddin wrote:
On Oct 18, 2006, at 6:52 AM, David H. DeWolf wrote:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be used
to provide application sco
On Oct 18, 2006, at 6:52 AM, David H. DeWolf wrote:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be
used to provide application scoped functions (e.g.
On Oct 19, 2006, at 10:24 AM, David H. DeWolf wrote:
Antonio Petrelli wrote:
David H. DeWolf ha scritto:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will
Antonio Petrelli wrote:
David H. DeWolf ha scritto:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be used
to provide application scoped functions (e.g. ge
send me the output/errors offline and we'll work through it.
David
Antonio Petrelli wrote:
David H. DeWolf ha scritto:
I figured out what I did. . .when refactoring I renamed classes such
as TilesContextFactory to BasicTilesContextFactory and then created a
new TilesContextFactory for the int
David H. DeWolf ha scritto:
I figured out what I did. . .when refactoring I renamed classes such
as TilesContextFactory to BasicTilesContextFactory and then created a
new TilesContextFactory for the interface. I guess the
rename-recreate sequence confused the three of us (me, subversion, and
I figured out what I did. . .when refactoring I renamed classes such as
TilesContextFactory to BasicTilesContextFactory and then created a new
TilesContextFactory for the interface. I guess the rename-recreate
sequence confused the three of us (me, subversion, and patch ;) )
Anywho. . .a new
David H. DeWolf ha scritto:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be used
to provide application scoped functions (e.g. getResource() or
getInitPar
SB-44 has been filed suggesting that the TilesContextFactory and it's
usages be refactored to remove the use of static methods. This will
allow different implementations of the factory to be used as an
extension point in Tiles.
When implementing this change, one thing that will be noticed is
20 matches
Mail list logo
