You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@apache.org> on 2001/03/16 14:38:09 UTC
Template Services
Hi,
I'm working on the template services today so could people stay
out of there for today if possible.
I have now rewritten a large chunk of the template service
so that the 'discovery' of templates is left to the template
engine being used.
The template service assumed that all templates would be found
in the file system which I think is a bit limiting. My end goal
is to be able to load flux from a JAR file: all the modules and
templates in a single JAR file, just drop it in and go.
What I have is working and is backward compatible, I am now
testing all the template engine services to make sure that
everything will work as it always has :-)
What I have done is created a TemplateEngineService interface
that services like the VelocityService must implement. When
the TemplateService starts it will grab the instance of the
TemplateEngineService that is running (yes this creates
dependencies between services, that's another message) and uses
that TemplateEngineService to 'discover' whether a requested
template exists or not. John may be the only one who fully
understands what I'm talking about so pipe up John if you
see anything wrong with this :-)
This will allow us to fully utilize the power of the template
engine. For example, Velocity can now load templates from
the file system, the classpath, JAR files, and databases. I would
like turbine users to have the choice of where there templates are
stored.
You will no longer have to specify path properties for both
the template service and the template engine service. You will
only have to configure template engine service. The template
service will delegate all the searching for templates to the
template engine.
The only thing the template service should do is match up a
screen class with a template, and match a layout template with
a screen template. It shouldn't be looking in the file system
for templates which it is currently doing.
That's the job of the template engine.
I will fully test this and make sure it works. It might take
me another day so to finish and I think the changes will
provide a lot of flexibility. If anyone has any strong
objections please let me know soon ;-)
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Template Services
Posted by John McNally <jm...@collab.net>.
I suggested this potential problem earlier and you were confident that
it was not a problem, but I would like to be a little more clear just to
make sure.
root1
layouts
default.vm
screens
index.vm
root2
layouts
default.vm
screens
index.vm
newpage.vm
Assume that root1 is search before root2
With the current service if newpage.vm is requested the
root2/layouts/default.vm will be picked as the layout. I do not see how
this behavior can be forced on the template engine service, since I
think it would most likely return root1/layouts/default.vm, since it
will find it first. Maybe it can be but I am not even sure of the
utility of the current matching scheme.
It would seem more useful to allow the default layout in root1 to
override the layout in root2 even if the template is found in root2. I
see the utility here in that it can allow branding. Where for example
newpage.vm is more like all_the_rest_of_the_apps_screens_.vm's and then
you stick a branding index page and layout on the app and it's set to
go.
Anyone using the current multiple doc root searching algorithm to their
advantage? Jason have you been able to mimic the current behavior with
all the template engines? (IIRC, which I probably don't, FreeMarker
only supported one root.)
John McNally
Jason van Zyl wrote:
>
> Hi,
>
> I'm working on the template services today so could people stay
> out of there for today if possible.
>
> I have now rewritten a large chunk of the template service
> so that the 'discovery' of templates is left to the template
> engine being used.
>
> The template service assumed that all templates would be found
> in the file system which I think is a bit limiting. My end goal
> is to be able to load flux from a JAR file: all the modules and
> templates in a single JAR file, just drop it in and go.
>
> What I have is working and is backward compatible, I am now
> testing all the template engine services to make sure that
> everything will work as it always has :-)
>
> What I have done is created a TemplateEngineService interface
> that services like the VelocityService must implement. When
> the TemplateService starts it will grab the instance of the
> TemplateEngineService that is running (yes this creates
> dependencies between services, that's another message) and uses
> that TemplateEngineService to 'discover' whether a requested
> template exists or not. John may be the only one who fully
> understands what I'm talking about so pipe up John if you
> see anything wrong with this :-)
>
> This will allow us to fully utilize the power of the template
> engine. For example, Velocity can now load templates from
> the file system, the classpath, JAR files, and databases. I would
> like turbine users to have the choice of where there templates are
> stored.
>
> You will no longer have to specify path properties for both
> the template service and the template engine service. You will
> only have to configure template engine service. The template
> service will delegate all the searching for templates to the
> template engine.
>
> The only thing the template service should do is match up a
> screen class with a template, and match a layout template with
> a screen template. It shouldn't be looking in the file system
> for templates which it is currently doing.
> That's the job of the template engine.
>
> I will fully test this and make sure it works. It might take
> me another day so to finish and I think the changes will
> provide a lot of flexibility. If anyone has any strong
> objections please let me know soon ;-)
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Template Services
Posted by Arkaitz <ar...@yahoo.com>.
Jason,
I'm not very versed in Turbine internals, but should this new change
make it easier to implement a template localization system? The way I've
thought it I would need a way to specify a Locale to the
TemplateService/Engine/Velocity per request (I'm a little bit lost :-)),
and it would do the "right thing", following the Java i18n rules. Do you
have any idea about where all this logic should go in the new scheme of
things?
I'm eagerly waiting for TDK1.1a12 to test all this stuff ;-).
Thanks for all the great work!
Cheers,
Arkaitz.
On 16 Mar 2001 08:38:09 -0500, Jason van Zyl wrote:
> Hi,
>
> I'm working on the template services today so could people stay
> out of there for today if possible.
>
> I have now rewritten a large chunk of the template service
> so that the 'discovery' of templates is left to the template
> engine being used.
>
> The template service assumed that all templates would be found
> in the file system which I think is a bit limiting. My end goal
> is to be able to load flux from a JAR file: all the modules and
> templates in a single JAR file, just drop it in and go.
>
> What I have is working and is backward compatible, I am now
> testing all the template engine services to make sure that
> everything will work as it always has :-)
>
> What I have done is created a TemplateEngineService interface
> that services like the VelocityService must implement. When
> the TemplateService starts it will grab the instance of the
> TemplateEngineService that is running (yes this creates
> dependencies between services, that's another message) and uses
> that TemplateEngineService to 'discover' whether a requested
> template exists or not. John may be the only one who fully
> understands what I'm talking about so pipe up John if you
> see anything wrong with this :-)
>
> This will allow us to fully utilize the power of the template
> engine. For example, Velocity can now load templates from
> the file system, the classpath, JAR files, and databases. I would
> like turbine users to have the choice of where there templates are
> stored.
>
> You will no longer have to specify path properties for both
> the template service and the template engine service. You will
> only have to configure template engine service. The template
> service will delegate all the searching for templates to the
> template engine.
>
> The only thing the template service should do is match up a
> screen class with a template, and match a layout template with
> a screen template. It shouldn't be looking in the file system
> for templates which it is currently doing.
> That's the job of the template engine.
>
> I will fully test this and make sure it works. It might take
> me another day so to finish and I think the changes will
> provide a lot of flexibility. If anyone has any strong
> objections please let me know soon ;-)
>
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Template Services
Posted by ingo schuster <in...@web.de>.
Jason,
sorry for answering that late... Great, that you are refactoring the
template service.
>I have now rewritten a large chunk of the template service
>so that the 'discovery' of templates is left to the template
>engine being used.
Can you explain this in more detail. E.g. with JSPs, do you say that the
template service just passed one single template(path) and it is left to
the JSP engine to check whether the file can be found or not, or will there
an additional piece of code between the TurbineTemplate service and the
template processor that can be customized to search a number of pathes for
the template file? Would such code be located in the TemplateEngineService?
The background why I'm asking is following. I implemented a sort of
multi-language support in jetspeed that based on templates being in a
respecive directory structure, with a fallback mechanism to reduce the
number of template files if possible. To give an example:
A template name "/html/en/US/IE/mytemplate" would result in a search for
following files (in the given order):
1. /html/en/US/IE/mytemplate
2. /html/en/US/mytemplate
3. /html/en/mytemplate
4. /html/mytemplate
5. /mytemplate
Am I right to assume that this functionality would be implemented by
subclassing the EngineService?
One problem I had with the current implementation is hat it was virtually
impossible to subclass the Turbine TemplateService, as it defined *many*
methods and filds as private. With the new implementation, can you please
keep this in mind and use declare "privates" only where absolutely
necessary, and better use "protected" instead?
Thanks, and again sorry for the late comment.
ingo.
At 15:38 03/16/01, Jason van Zyl wrote:
>Hi,
>
>I'm working on the template services today so could people stay
>out of there for today if possible.
>
>I have now rewritten a large chunk of the template service
>so that the 'discovery' of templates is left to the template
>engine being used.
>
>The template service assumed that all templates would be found
>in the file system which I think is a bit limiting. My end goal
>is to be able to load flux from a JAR file: all the modules and
>templates in a single JAR file, just drop it in and go.
>
>What I have is working and is backward compatible, I am now
>testing all the template engine services to make sure that
>everything will work as it always has :-)
>
>What I have done is created a TemplateEngineService interface
>that services like the VelocityService must implement. When
>the TemplateService starts it will grab the instance of the
>TemplateEngineService that is running (yes this creates
>dependencies between services, that's another message) and uses
>that TemplateEngineService to 'discover' whether a requested
>template exists or not. John may be the only one who fully
>understands what I'm talking about so pipe up John if you
>see anything wrong with this :-)
>
>This will allow us to fully utilize the power of the template
>engine. For example, Velocity can now load templates from
>the file system, the classpath, JAR files, and databases. I would
>like turbine users to have the choice of where there templates are
>stored.
>
>You will no longer have to specify path properties for both
>the template service and the template engine service. You will
>only have to configure template engine service. The template
>service will delegate all the searching for templates to the
>template engine.
>
>The only thing the template service should do is match up a
>screen class with a template, and match a layout template with
>a screen template. It shouldn't be looking in the file system
>for templates which it is currently doing.
>That's the job of the template engine.
>
>I will fully test this and make sure it works. It might take
>me another day so to finish and I think the changes will
>provide a lot of flexibility. If anyone has any strong
>objections please let me know soon ;-)
>
>
>--
>jvz.
>
>Jason van Zyl
>jvanzyl@periapt.com
>
>http://jakarta.apache.org/velocity
>http://jakarta.apache.org/turbine
>http://tambora.zenplex.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Template Services
Posted by Daniel Rall <dl...@collab.net>.
Jason van Zyl <jv...@apache.org> writes:
> Ilkka Priha wrote:
> >
> > This is great. And this is a convenient opportunity to propose one addition
> > to the search mechanism. If you're using a template naming scheme, where the
> > extension is not e.g. vm for Velocity templates, but wml, hdml, html, etc
> > for different markup language specific templates, the current search
> > mechanism doesn't fully support this approach.
> >
> > The idea is to specify all default templates in TR without extensions and
> > then apply the extension coming from the URL to the defaults. Currently, the
> > mechanism adds the one and only default extension to default layout and
> > navigation templates, if the extension is not included in the TR template
> > spec. It would be nice, if it could first check whether the incoming screen
> > template name contains an extension and then apply this extension to
> > extensionless default templates.
> >
> > -- Ilkka
> >
>
> Ok, I will keep this in mind while I'm making the changes :-)
> Good idea!
Yay! I was planning on doing this in Tigris. Now I won't have to...
;)
--
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Template Services
Posted by Jason van Zyl <jv...@apache.org>.
Ilkka Priha wrote:
>
> This is great. And this is a convenient opportunity to propose one addition
> to the search mechanism. If you're using a template naming scheme, where the
> extension is not e.g. vm for Velocity templates, but wml, hdml, html, etc
> for different markup language specific templates, the current search
> mechanism doesn't fully support this approach.
>
> The idea is to specify all default templates in TR without extensions and
> then apply the extension coming from the URL to the defaults. Currently, the
> mechanism adds the one and only default extension to default layout and
> navigation templates, if the extension is not included in the TR template
> spec. It would be nice, if it could first check whether the incoming screen
> template name contains an extension and then apply this extension to
> extensionless default templates.
>
> -- Ilkka
>
Ok, I will keep this in mind while I'm making the changes :-)
Good idea!
> > --
> > jvz.
> >
> > Jason van Zyl
> > jvanzyl@periapt.com
> >
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/turbine
> > http://tambora.zenplex.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Template Services
Posted by Ilkka Priha <ex...@nokia.com>.
This is great. And this is a convenient opportunity to propose one addition
to the search mechanism. If you're using a template naming scheme, where the
extension is not e.g. vm for Velocity templates, but wml, hdml, html, etc
for different markup language specific templates, the current search
mechanism doesn't fully support this approach.
The idea is to specify all default templates in TR without extensions and
then apply the extension coming from the URL to the defaults. Currently, the
mechanism adds the one and only default extension to default layout and
navigation templates, if the extension is not included in the TR template
spec. It would be nice, if it could first check whether the incoming screen
template name contains an extension and then apply this extension to
extensionless default templates.
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
> -----Original Message-----
> From: jvanzyl [mailto:jvanzyl]On Behalf Of Jason van Zyl
> Sent: Friday, March 16, 2001 15:38
> To: turbine-dev@jakarta.apache.org
> Subject: Template Services
>
>
> Hi,
>
> I'm working on the template services today so could people stay
> out of there for today if possible.
>
> I have now rewritten a large chunk of the template service
> so that the 'discovery' of templates is left to the template
> engine being used.
>
> The template service assumed that all templates would be found
> in the file system which I think is a bit limiting. My end goal
> is to be able to load flux from a JAR file: all the modules and
> templates in a single JAR file, just drop it in and go.
>
> What I have is working and is backward compatible, I am now
> testing all the template engine services to make sure that
> everything will work as it always has :-)
>
> What I have done is created a TemplateEngineService interface
> that services like the VelocityService must implement. When
> the TemplateService starts it will grab the instance of the
> TemplateEngineService that is running (yes this creates
> dependencies between services, that's another message) and uses
> that TemplateEngineService to 'discover' whether a requested
> template exists or not. John may be the only one who fully
> understands what I'm talking about so pipe up John if you
> see anything wrong with this :-)
>
> This will allow us to fully utilize the power of the template
> engine. For example, Velocity can now load templates from
> the file system, the classpath, JAR files, and databases. I would
> like turbine users to have the choice of where there templates are
> stored.
>
> You will no longer have to specify path properties for both
> the template service and the template engine service. You will
> only have to configure template engine service. The template
> service will delegate all the searching for templates to the
> template engine.
>
> The only thing the template service should do is match up a
> screen class with a template, and match a layout template with
> a screen template. It shouldn't be looking in the file system
> for templates which it is currently doing.
> That's the job of the template engine.
>
> I will fully test this and make sure it works. It might take
> me another day so to finish and I think the changes will
> provide a lot of flexibility. If anyone has any strong
> objections please let me know soon ;-)
>
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org