On Fri, Jun 07, 2002 at 07:55:55AM -0400, darren chamberlain wrote: > The real solution to this is to make every element of TT that can be > controlled by a configuration parameter be modifiable by a mutator > method, and, at the beginning of each request, modify the appropriate > aspects of the Template objects.
I was thinking about this kind of thing wrt to the design of TT3. I'm planning to have a Template::Arena in which you can define multiple providers, filters, etc., etc. Everything that you might want to share between different processors is referenced from here. Services are created as children of the arena. When a service is invoked, it creates, or reuses an existing context object which defines the particular vieiw of part of the arena that the service requires. In TT2, the context is fairly static. You have to go poking around in the inside to change stuff and it's all a bit dirty. In TT3 you should also be able to use the context in the same way, but it should also provide support for having multiple pre-defined contexts which can be selected according to some parameter, and also generate custom contexts on the fly. So, the Arena is the time and space invariant model, the services represent different ways of interacting with the arena, and the context represents a particular instance (e.g. request) of a service interacting with the arena. That should make it as clear as mud :-) Anyway, I'm hoping that it'll provide a single hook where can you define your own strategies for building, customising or otherwise tinkering with the context and other components that get selected for a service. A
