Here's a summary about what I did/about to do to cvs for -3 source:
Made Resolver an interface:
init()
getTemplate()
getModule()
The property <resolver.default> is used to specific your own resolver in the TR.
e.g. resolver.default = org.apache.turbine.pipeline.DefaultResolver
Turbine.java now loads the resolver in configure()
Added a class DefaultResolver.java. It is the original code of the
Resolver and the method getModule() just calls the ModuleLoader.getModule()
as the default.
I moved the method getPossibleModules() from the old Resolver to the
ModuleLoader (only the ModuleLoader used it anyway).
I changed all calls from Turbine.getModuleLoader().getModule() to
Turbine.getResolver().getModule()
I added a class called ModuleRunner, it's just is to run modules :) The
Renderer now only renders.
The Renderer now uses the Resolver. getFullPath() is no longer needed.
I added a class called PipeLineUtil. It contains a single method
parseTemplateFile() which is used in various parts. It was a static
method in the old Resolver.
I changed the ClassicPipeline to use the ModuleRunner and to use the
Resolver. I also keep in some of the comments that can now be removed.
I made a note by them (we now can use the renderer in the last step
of the pipeline).
I have tested all of this with one of my apps using
1. the latest version of torque
2. the latest version of fulcrum
3. the latest version of turbine-3
4. my own resolver
Everything runs well !!!!
I will test it against the default to be sure everything behaves as
it should
NOTES:
the logic used in the ModuleLoader for getModule(). It could
1. be moved in the DefaultResolver. Caching etc, could be done there
as well. The ModuleLoader would then not even be needed.
2. stay in the ModuleLoader as it is. If you want to use
a different algorithm for finding modules, you create your own
Resolver. The only problem with this choice is there are now two
ways to get a Module, Resolver.getModule() and ModuleLoader.getModule()
which can/will lead to confusion. It is important that all client
go through the Resolver to get the module and not bypass it by using
the ModuleLoader directly.
Also, the way we handle ',' and '/' as path separators could be
optimized. The TemplateService expects to see the ',', however
the resolver/module loader changes the ',' to '.' in order to find
the modules. The template resolver changes the ',' to '/' in
order to find the templates.
The problem with this is that these conversions are being done several
times per request. And are being re-done several times for the same search.
Perhaps it would be nice that when a target is set, the two conversions
are done and then cached. All other components could then use the cached
data (one of '.' ',' '/'). We can save a lot of time and memory
with this opt.
mike
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
