You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2000/12/10 08:05:45 UTC
Template-local Inline VMs
There is a new feature, Template-Local Inline VMs (TLIV), now checked in
and working. I would like to thank Jose Alberto Fernandez
(JFernandez@viquity.com) for both valuable public and private motivation
and discussion as well as work leading to this. He submitted to me a
patch at the same time that I had completed a solution. So I hijacked an
idea or two. :) The best part was that we had arrived at the same basic
technique for namespace management, so either this is comforting because
it argues it's the right way, or comforting that if it isn't, he gets
taken out and flogged with me :)
Summary
-------
TLIV is a feature in which a VM defined inline (inline := within a
template) is accessable only to the defining template.
When this feature is turned on, you may use inline VM definitions w/o
worry that another template will replace your VM definition.
It also means that it won't replace a globally defined VM.
This feature is OFF by default.
A new, useful behavior that you get using this is shown in the testbed,
vm_test1.vm and vm_test2.vm in association with VM_local_library.vm.
Very simply, VM_local_library.vm defines two VMs #callrecurse() and
#recurse(). When #callrecurse() is invoked, it invokes #recurse(). But
if you want a local variant of #recurse(), you can define it in the
template that wants the altered behavior. (Yes, like overloading a
method :) vm_test2.vm does this. Look at compare/vm_testX.cmp to see
the output. Because of testbed properties, this is run via a different
JUnit test, invoked by 'build-velocity.sh test-inlinevmscope' in the
build directory.
Useful? I think so. You can define a series of actions started by a
controlling global (or local) VM, say rendering some part of a web
page. The global VMs will be called unless you have a local VM with the
same name, so you can have a base/default with localized presentation.
I think this is the right behavior : when you turn on TLIV, you are
saying that when you invoke #foo() in a template, if defined in that
template, you want that definition of #foo(). Therefore, which #foo()
should not be dependant upon invocation path ( such as if it was invoked
by a global VM.)
Details
-------
To activate, set in your velocity.properties file the following :
velocimacro.permissions.allowInlineLocalScope = true
The rules used by the VMFactory for accepting VM definitions is as
follows :
are they allowed at all ? (velocimacro.permissions.allowInline)
no : reject
yes : is TLIV turned on ?
(velocimacro.permissions.allowInlineLocalScope )
yes : accept for the defining template *
no : can inline VMs replace global (
velocimacro.permissions.allowInlineToReplaceGlobal )
yes : accept for global namespace
no : does this VM exist in global namespace?
no : accept (because we aren't replacing ) **
yes : reject
* because by definition, it not replacing anything : this happens at
template init time and the namespace is cleared at parse time for that
template
** some may argue with this -> maybe we want this to mean, can a VM
affect the global namespace, or just add other for this. Yes, maybe
that's it. Discussion
I think I tested this rather well, let me know if any problems.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Template-local Inline VMs
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rafal Krzewski wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > > You mean that a macro defined in one template file can silently replace
> > > a macro defined in another file at runtime? Yuck!
> >
> > It's not silent, there is a switch, its off by default, and it has been
> > that way since the beginning. It was recognized as yecchy, so thats why
> > there is a swtich, default off.
>
> I don't understand what good could turning it on do, but let's assume
> that
> I don't need to. As long as it's off by default, it's fine with me.
I guess the use is that you can add or alter templates in a running vel
engine for all to use, rather than bouncing it. We'll add admin tools
later I guess to avoid both methods :)
It's scary to me too : there is a test in the testbed to ensure that
it's off by default :)
> > 1) have to try to put the two templates named 'View.vm' into the same
> > directory (in which case they *should* notice a problem - if not, maybe
> > these television-typewriter thingys aren't for them... :)
> <snip>
> > Did I miss anything?
>
> After clarifying that you meant template path not only the file name,
> it sounds much, much better :-)
Yes. It's not the full path (the absolute path on disk) but relative to
the node on the search path. This might/will have to change later as we
add other template sources, but we might want to see how it goes for
now. It's an internal issue, so we don't affect users if we change
anything later.
> Thanks for explanations!
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Template-local Inline VMs
Posted by Rafal Krzewski <Ra...@e-point.pl>.
"Geir Magnusson Jr." wrote:
> > You mean that a macro defined in one template file can silently replace
> > a macro defined in another file at runtime? Yuck!
>
> It's not silent, there is a switch, its off by default, and it has been
> that way since the beginning. It was recognized as yecchy, so thats why
> there is a swtich, default off.
I don't understand what good could turning it on do, but let's assume
that
I don't need to. As long as it's off by default, it's fine with me.
> 1) have to try to put the two templates named 'View.vm' into the same
> directory (in which case they *should* notice a problem - if not, maybe
> these television-typewriter thingys aren't for them... :)
<snip>
> Did I miss anything?
After clarifying that you meant template path not only the file name,
it sounds much, much better :-)
Thanks for explanations!
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
RE: Using stylesheets with Velocity
Posted by Magnus ?or Torfason <ma...@handtolvur.is>.
>
> I guess you meant within the Turbine environment... So your
> post went sort of to the wrong list.
>
Hey, and I subscribed to this list just so that my fellow
Turbiners wouldn't scream at me for posting a Velocity
question to the turbine list :(
Thanks anyway, your response was very helpful.
Magnus Torfason
Re: Using stylesheets with Velocity
Posted by Christoph Reck <Ch...@dlr.de>.
I guess you meant within the Turbine environment... So your
post went sort of to the wrong list.
Re: Using stylesheets with Velocity
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Magnus ?or Torfason wrote:
>
> Hi,
>
> I want each of my velocity screen templates to be able to
> specify a stylesheet to use, what I want is essentially
>
> <head>
>
> <title>My Title</title>
>
> <!-- The following line is what I need. -->
> <link href="/mywebapp/mystylesheet.css" rel="stylesheet">
>
> </head>
>
> I'm guessing it has something to do with $page, but have
> not found any documentation on it's use.
>
> Thanks for any assistance.
This is the velocity list, and I assume this is a Turbine question?
There are lots of Turbiners slinking around, but still. We like at
least to pretend... :)
If not a Turbine question, and indeed a Velocity question, put the css
you want to use into the context in your app or servlet :
context.put("css", "mystylesheet1.css" );
Do what you need to do with the second arg above. (if you have some
object, drop it in and invoke the method in the template...)
If you do as above, then in your template
<link href="/mywebapp/$css" rel="stylesheet">
should do the trick.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Using stylesheets with Velocity
Posted by Christoph Reck <Ch...@dlr.de>.
My previous response was ripped apart (due to the contained
line starting with From), here it is again in full beauty:
I guess you meant within the Turbine environment... So your
post went sort of to the wrong list.
:From Velocity point of view, if that's the output you want, just
write it so ;)
Within Turbine, it depends if you are using the VelocityECSLayout
or the VelocityOnlyLayout.
a) For the ECS Layout you use:
#set $page.StyleSheet = $content.("mystylesheet.css")
(Note I'm reffering to the new ContentURI class added last
friday to turbine and to the context.)
b) For the VelocityOnlyLayout you would need to do this
by hand. Rafal Krzewski is preparing a HeadTool and a sample
layout template for this purpose.
See the "Script into HTML-Head" thread in the turbine list.
:) Christoph
Magnus ?or Torfason wrote:
>
> Hi,
>
> I want each of my velocity screen templates to be able to
> specify a stylesheet to use, what I want is essentially
>
> <head>
>
> <title>My Title</title>
>
> <!-- The following line is what I need. -->
> <link href="/mywebapp/mystylesheet.css" rel="stylesheet">
>
> </head>
>
> I'm guessing it has something to do with $page, but have
> not found any documentation on it's use.
>
> Thanks for any assistance.
Using stylesheets with Velocity
Posted by Magnus ?or Torfason <ma...@handtolvur.is>.
Hi,
I want each of my velocity screen templates to be able to
specify a stylesheet to use, what I want is essentially
<head>
<title>My Title</title>
<!-- The following line is what I need. -->
<link href="/mywebapp/mystylesheet.css" rel="stylesheet">
</head>
I'm guessing it has something to do with $page, but have
not found any documentation on it's use.
Thanks for any assistance.
Re: Template-local Inline VMs
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rafal Krzewski wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > > > no : can inline VMs replace global ( allowInlineToReplaceGlobal )
> > > > yes : accept for global namespace
> > >
> > > does this mean that it overwrites the global and is visible
> > > from there on to other templates? Scary!
> >
> > Yes. It's been that way since the beginning.
>
> I didn't follow your heated discussion very closely, but looking at this
> very
> message, I think that something *really scary* is going on.
>
> You mean that a macro defined in one template file can silently replace
> a macro defined in another file at runtime? Yuck!
>
It's not silent, there is a switch, its off by default, and it has been
that way since the beginning. It was recognized as yecchy, so thats why
there is a swtich, default off.
> > As long as you don't all use the same name for your templates, it will
> > work. If you use the same name for your templates, you will certainly
> > have other problems. :)
>
> It will work as long as you dont have two people working on one
> aplication
> and they dont create two templates named View.vm in different
> directories,
> and they dont define macros named #tablerow()...
> Come on, it seems more than probable...
No, I think, because they :
1) have to try to put the two templates named 'View.vm' into the same
directory (in which case they *should* notice a problem - if not, maybe
these television-typewriter thingys aren't for them... :)
2) in a multi-directory template path, put them in different directories
on the template path, in which case the one in the first directory in
the template path will be used for both users' requests, in which case
it won't be a VM issue they will be complaining about at first :)
3) they will have the two 'View.vm' files in different subdirectories
(of the same template path element or not), in which case the namespace
used for the VMs would be different. In one case it would be
"directory_a/View.vm" and for the other "directory_b/View.vm". If they
are the same subdir name in different nodes of the template path, see #2
above.
Are there any other possibilities? My point is that I think this is a
non-issue; since with a single instance of the Velocity runtime, until
we lose what's left of our minds and randomize the template search
algorithm, you can't have two templates of the same name at all, unless
you distinguish them somehow.
Did I miss anything?
geir
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Template-local Inline VMs
Posted by Rafal Krzewski <Ra...@e-point.pl>.
"Geir Magnusson Jr." wrote:
> > > no : can inline VMs replace global ( allowInlineToReplaceGlobal )
> > > yes : accept for global namespace
> >
> > does this mean that it overwrites the global and is visible
> > from there on to other templates? Scary!
>
> Yes. It's been that way since the beginning.
I didn't follow your heated discussion very closely, but looking at this
very
message, I think that something *really scary* is going on.
You mean that a macro defined in one template file can silently replace
a macro defined in another file at runtime? Yuck!
> As long as you don't all use the same name for your templates, it will
> work. If you use the same name for your templates, you will certainly
> have other problems. :)
It will work as long as you dont have two people working on one
aplication
and they dont create two templates named View.vm in different
directories,
and they dont define macros named #tablerow()...
Come on, it seems more than probable...
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
Re: Template-local Inline VMs
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christoph Reck wrote:
>
> The combination of:
> Macro.java
> VelocimacroProxy.java
> VelocimacroFactory.java
> VelocimacroManager.java
> Parser.jjt
> ASTDirective.java
> namespaces
> properties
> etc.
> Is not a very simple and trasparent construct. VMs seem very hardwired
> into the engine... I guess the rules (eloquated some more) need to
> flow into the docs.
?
> > The rules used by the VMFactory for accepting VM definitions is as
> > follows :
> >
> > are they allowed at all ? (velocimacro.permissions.allowInline)
> > no : reject
> > yes : is TLIV turned on ?
> > (velocimacro.permissions.allowInlineLocalScope )
> > yes : accept for the defining template *
>
> With the local namespace, only accessible within this template?
Yes, of course.
> > no : can inline VMs replace global ( allowInlineToReplaceGlobal )
> > yes : accept for global namespace
>
> does this mean that it overwrites the global and is visible
> from there on to other templates? Scary!
Yes. It's been that way since the beginning.
> > no : does this VM exist in global namespace?
> > no : accept (because we aren't replacing ) **
>
> With the global namespace, accessible from other templates?
>
> > yes : reject
>
> In general I think I get it, so I'll be able to do what I need in my
> application...
>
> I hope it also works for others that need many NS in one JVM.
As long as you don't all use the same name for your templates, it will
work. If you use the same name for your templates, you will certainly
have other problems. :)
> :) Christoph
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Template-local Inline VMs
Posted by Christoph Reck <Ch...@dlr.de>.
The combination of:
Macro.java
VelocimacroProxy.java
VelocimacroFactory.java
VelocimacroManager.java
Parser.jjt
ASTDirective.java
namespaces
properties
etc.
Is not a very simple and trasparent construct. VMs seem very hardwired
into the engine... I guess the rules (eloquated some more) need to
flow into the docs.
> The rules used by the VMFactory for accepting VM definitions is as
> follows :
>
> are they allowed at all ? (velocimacro.permissions.allowInline)
> no : reject
> yes : is TLIV turned on ?
> (velocimacro.permissions.allowInlineLocalScope )
> yes : accept for the defining template *
With the local namespace, only accessible within this template?
> no : can inline VMs replace global ( allowInlineToReplaceGlobal )
> yes : accept for global namespace
does this mean that it overwrites the global and is visible
from there on to other templates? Scary!
> no : does this VM exist in global namespace?
> no : accept (because we aren't replacing ) **
With the global namespace, accessible from other templates?
> yes : reject
In general I think I get it, so I'll be able to do what I need in my
application...
I hope it also works for others that need many NS in one JVM.
:) Christoph