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 patch is now attached to the issue. Regarding your
comments, see below
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. getResource() or
getInitParameters()) . The TilesRequestContext will provide
request/response specific operations (e.g. include() or getParameters()).
It seems like a good idea, anyway I would like to know from Greg if it
is ok for him.
Yes, me too.
2) The TilesContext is instantiated by a configured instance of the
TilesContextFactory at startup (indirectly by the TilesServlet,
TilesFilter, TilesListener or any other initialization feature the
client decides to implement).
For configuration, I would like something like the configuration of
DefinitionsReader, take a look at UrlDefinitionsFactory for that.
Agreed. The current patch does not provide such configuration, it
simply instantiates the BasicTilesContextFactory and proceeds (one step
at a time). Once we have agreement and this patch committed, I'll go
ahead and implement the configuration as you suggest.
3) In the servlet/portlet environment the TilesContext will be saved
as a ServletContext attribute and will be retrieved from here by the
tags and other dependent objects. (Other environments will need their
own mechanism and will be handled in their initialization)
4) The TilesRequestContext will be created by a method on the
TilesContext (createRequestContext(request, response).
I think that a utility class could be, err..., useful :-)
If you prefer, yes, we could, however, it's not unreasonable to assume
that someone wanting to provide their own TilesContext implementation
would also want to implement their own TilesRequestContext. If the
former acts as a factory for the latter, they continue to work as a pair
and can be implemented together. By moving to a utility class we either
sacrifice this second customization point or have to manage the
propagation of yet another factory - and this time it'll be used
throughout the code instead of just at initialization.
Great work David! I really liked your ideas. It's a pity that it is
ruined by your patch, come on, clean it up! :-)
Tell me about it! If the darn new guy could just figure out how to use
some basic tools ;)
Thanks,
David
Ciao
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]
