You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Tom Dunstan <to...@intecgroup.com.au> on 2002/05/03 06:07:11 UTC
Macros defined in parsed pages not available on first display
Hi
I'm experiencing some odd behaviour using Velocity 1.3-rc1 in conjunction
with struts and the VelocityViewServlet.
In a template which includes another template using #parse, any macros
defined in the sub-template don't get rendered the first time the page is
viewed, but appear after that.
Example:
macro.vm:
#macro(test, $param)
Macro: param was $param
#end
test.vm:
#parse("macro.vm")
#test("blurg")
The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
times shows "Macro: param was blurg", as expected.
Any suggestions?
Thanks
--
Tom Dunstan
Intec Consulting Group
Tel: +61 8 8359 2332
Mob: 0417 895 244
tom.dunstan@intecgroup.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Gabriel Sidler <si...@teamup.ch>.
Christoph,
Thanks, that was an excellent tip. We were able to locate the
problem and fix it. It was not a Velocity problem. Sorry for
the false alarm.
What remains an open issues is the problem reported by Tom Dunstan
(macros don't get evaluated the first time around)
Gabe
Christoph Reck wrote:
> Gabriel,
>
> could you ask your colleague to test very first request to his
> VelocityStruts application by hitting it with something like (unix)
> telnet yourserver 80
> GET /path/to/the/VelocityStruts/servlet/and/template HTTP1.1
>
> This should help in finding out what was really sent - including
> HTTP headers, etc.
>
>
> Gabriel Sidler wrote:
>
>>Tom Dunstan wrote:
>>
> [snip]
>
>>>The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
>>>times shows "Macro: param was blurg", as expected.
>>>
>>Yup, I can reproduce the same problem here but I can't explain. Geir,
>>any suggestions?
>>
>>A colleague reported another very strange macro-related problem to me.
>>He is using the VelocityStrust package to create the view of a Struts
>>application. He has defined several macros in the VM_global_library.vm
>>file. He reports that on the very first request to a vm file after startup,
>>the content of VM_global_library.vm is display in his browser for a
>>split second. Then it is overloaded with the requested template.
>>This is baffling me. How is this possible?
>>
>>Gabe
>>
>>
>>>Any suggestions?
>>>
>>>Thanks
>>>
>
--
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Christoph Reck <Ch...@dlr.de>.
Gabriel,
could you ask your colleague to test very first request to his
VelocityStruts application by hitting it with something like (unix)
telnet yourserver 80
GET /path/to/the/VelocityStruts/servlet/and/template HTTP1.1
This should help in finding out what was really sent - including
HTTP headers, etc.
Gabriel Sidler wrote:
>
> Tom Dunstan wrote:
[snip]
> > The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
> > times shows "Macro: param was blurg", as expected.
>
> Yup, I can reproduce the same problem here but I can't explain. Geir,
> any suggestions?
>
> A colleague reported another very strange macro-related problem to me.
> He is using the VelocityStrust package to create the view of a Struts
> application. He has defined several macros in the VM_global_library.vm
> file. He reports that on the very first request to a vm file after startup,
> the content of VM_global_library.vm is display in his browser for a
> split second. Then it is overloaded with the requested template.
> This is baffling me. How is this possible?
>
> Gabe
>
> >
> > Any suggestions?
> >
> > Thanks
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/3/02 12:23 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Tom Dunstan wrote:
>
>> Hi
>>
>> I'm experiencing some odd behaviour using Velocity 1.3-rc1 in conjunction
>> with struts and the VelocityViewServlet.
>>
>> In a template which includes another template using #parse, any macros
>> defined in the sub-template don't get rendered the first time the page is
>> viewed, but appear after that.
>>
>> Example:
>>
>> macro.vm:
>> #macro(test, $param)
>> Macro: param was $param
>> #end
>>
>>
>> test.vm:
>> #parse("macro.vm")
>> #test("blurg")
>>
>>
>> The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
>> times shows "Macro: param was blurg", as expected.
>
>
>
> Yup, I can reproduce the same problem here but I can't explain. Geir,
> any suggestions?
I'll try to knock off a bunch of these tis weekend. I have the parser in
pieces right now (trying to solve a bug last Saturday took me down a path I
was resisting for a long time ...) but when I get that together, I was
planning a real macro-fest.
>
> A colleague reported another very strange macro-related problem to me.
> He is using the VelocityStrust package to create the view of a Struts
> application. He has defined several macros in the VM_global_library.vm
> file. He reports that on the very first request to a vm file after startup,
> the content of VM_global_library.vm is display in his browser for a
> split second. Then it is overloaded with the requested template.
> This is baffling me. How is this possible?
That's really weird. I've got to try it...
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Gabriel Sidler <si...@teamup.ch>.
Tom Dunstan wrote:
> Hi
>
> I'm experiencing some odd behaviour using Velocity 1.3-rc1 in conjunction
> with struts and the VelocityViewServlet.
>
> In a template which includes another template using #parse, any macros
> defined in the sub-template don't get rendered the first time the page is
> viewed, but appear after that.
>
> Example:
>
> macro.vm:
> #macro(test, $param)
> Macro: param was $param
> #end
>
>
> test.vm:
> #parse("macro.vm")
> #test("blurg")
>
>
> The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
> times shows "Macro: param was blurg", as expected.
Yup, I can reproduce the same problem here but I can't explain. Geir,
any suggestions?
A colleague reported another very strange macro-related problem to me.
He is using the VelocityStrust package to create the view of a Struts
application. He has defined several macros in the VM_global_library.vm
file. He reports that on the very first request to a vm file after startup,
the content of VM_global_library.vm is display in his browser for a
split second. Then it is overloaded with the requested template.
This is baffling me. How is this possible?
Gabe
>
> Any suggestions?
>
> Thanks
>
> --
> Tom Dunstan
> Intec Consulting Group
> Tel: +61 8 8359 2332
> Mob: 0417 895 244
> tom.dunstan@intecgroup.com.au
>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Tom Dunstan <to...@intecgroup.com.au>.
On Wed, 2002-05-08 at 14:38, Geir Magnusson Jr. wrote:
> :)
>
> I would have to cache all the combinations. It certainly could be done, but
> there are some other approaches that don't require that fundamental a
> change.
Well, you still end up only caching as many templates as are actually
requested, right?
I agree with you, btw. There are certainly other, probably better
solutions. I just wasn't sure why this one was so horrible. :)
Sorry, I do tend to play devil's advocate sometimes. I'll try to curb
it.
> > Perhaps I'm getting the wrong end of the stick. Are macros intended to
> > only be defined in the current page or in a library?
>
> More or less - what problem are you trying to solve that makes you need the
> VMs 'just in time'?
Including them dynamically meant that I didn't have to work out how to
set libraries up. :) That's all it was. I just saw a #parse and thought
"That'll do" without realizing that that wasn't really what it was
intended for. *shrug* I'll go away and read up on libraries now.
Cheers
Tom
--
Tom Dunstan
Intec Consulting Group
Phone: +61 8 83592332
Mobile: 0417 895 244
Email: tom.dunstan@intecgroup.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/8/02 12:56 AM, "Tom Dunstan" <to...@intecgroup.com.au> wrote:
> Hi
>
>>> The other, less nice way to do stuff is as a two pass thing (ie expand
>>> #parse directives first, then parse properly), but I don't know enough
>>> about how the parser etc works to know if that's feasible. :)
>>
>> That would crush performance, as you couldn't cache anything.
>
> Why not? Couldn't you cache the subsequently-parsed tree instead? You'd
> need to keep track of which files you had to parse, though, so that if
> any of them changed, you could re-parse the original file. That would
> impact a little bit on performance, but not as much as no caching at
> all.
:)
I would have to cache all the combinations. It certainly could be done, but
there are some other approaches that don't require that fundamental a
change.
>
>>> I recall someone wanting to substitute bits of velocity code into
>>> variables (possibly they wanted templates stored in a database or
>>> something similar), and thinking "What we really need, to be able to do
>>> that, is #eval". That's probably opening up a mega can of worms, though.
>>> :) I don't need that functionality personally (not right now, anyway),
>>> but if these issues are being thought about, I might as well throw it
>>> in.
>>
>> It's easy to do with a tool that wraps an instance of the Velocity engine
>> (or the one you are using for the template you want to eval in) and then use
>> the evalute() method(s).
>
> Yeah, that's what I thought. Would that work for macros defined in the
> current template, though?
>
> Perhaps I'm getting the wrong end of the stick. Are macros intended to
> only be defined in the current page or in a library?
More or less - what problem are you trying to solve that makes you need the
VMs 'just in time'?
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Tom Dunstan <to...@intecgroup.com.au>.
Hi
> > The other, less nice way to do stuff is as a two pass thing (ie expand
> > #parse directives first, then parse properly), but I don't know enough
> > about how the parser etc works to know if that's feasible. :)
>
> That would crush performance, as you couldn't cache anything.
Why not? Couldn't you cache the subsequently-parsed tree instead? You'd
need to keep track of which files you had to parse, though, so that if
any of them changed, you could re-parse the original file. That would
impact a little bit on performance, but not as much as no caching at
all.
> > I recall someone wanting to substitute bits of velocity code into
> > variables (possibly they wanted templates stored in a database or
> > something similar), and thinking "What we really need, to be able to do
> > that, is #eval". That's probably opening up a mega can of worms, though.
> > :) I don't need that functionality personally (not right now, anyway),
> > but if these issues are being thought about, I might as well throw it
> > in.
>
> It's easy to do with a tool that wraps an instance of the Velocity engine
> (or the one you are using for the template you want to eval in) and then use
> the evalute() method(s).
Yeah, that's what I thought. Would that work for macros defined in the
current template, though?
Perhaps I'm getting the wrong end of the stick. Are macros intended to
only be defined in the current page or in a library?
Thanks
Tom
--
Tom Dunstan
Intec Consulting Group
Phone: +61 8 83592332
Mobile: 0417 895 244
Email: tom.dunstan@intecgroup.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/7/02 11:38 PM, "Tom Dunstan" <to...@intecgroup.com.au> wrote:
>> Yes - the issue is that the #parse() doesn't get executed until runtime,
>> while the recognition of #<token>( (<arg))* ) is done at parse time - so the
>> 'test' VM doesn't exist until runtime.
>>
>> I have been musing about doing lazy, runtime determination for
>> directive-like things, and will see if we can get it in this time around.
>
> Like keeping a hash of all undetermined macro/directive like stuff at
> parse time which gets substituted back in at runtime?
>
> The other, less nice way to do stuff is as a two pass thing (ie expand
> #parse directives first, then parse properly), but I don't know enough
> about how the parser etc works to know if that's feasible. :)
That would crush performance, as you couldn't cache anything.
>
> I recall someone wanting to substitute bits of velocity code into
> variables (possibly they wanted templates stored in a database or
> something similar), and thinking "What we really need, to be able to do
> that, is #eval". That's probably opening up a mega can of worms, though.
> :) I don't need that functionality personally (not right now, anyway),
> but if these issues are being thought about, I might as well throw it
> in.
It's easy to do with a tool that wraps an instance of the Velocity engine
(or the one you are using for the template you want to eval in) and then use
the evalute() method(s).
>
> Getting back to the subject of this thread ...
>
> As a workaround, if I put the macros in a library script and load it at
> startup as a library, will that work (since it'll already be loaded
> before the script is parsed)?
Yes.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by Tom Dunstan <to...@intecgroup.com.au>.
> Yes - the issue is that the #parse() doesn't get executed until runtime,
> while the recognition of #<token>( (<arg))* ) is done at parse time - so the
> 'test' VM doesn't exist until runtime.
>
> I have been musing about doing lazy, runtime determination for
> directive-like things, and will see if we can get it in this time around.
Like keeping a hash of all undetermined macro/directive like stuff at
parse time which gets substituted back in at runtime?
The other, less nice way to do stuff is as a two pass thing (ie expand
#parse directives first, then parse properly), but I don't know enough
about how the parser etc works to know if that's feasible. :)
I recall someone wanting to substitute bits of velocity code into
variables (possibly they wanted templates stored in a database or
something similar), and thinking "What we really need, to be able to do
that, is #eval". That's probably opening up a mega can of worms, though.
:) I don't need that functionality personally (not right now, anyway),
but if these issues are being thought about, I might as well throw it
in.
Getting back to the subject of this thread ...
As a workaround, if I put the macros in a library script and load it at
startup as a library, will that work (since it'll already be loaded
before the script is parsed)?
Thanks
Tom
--
Tom Dunstan
Intec Consulting Group
Phone: +61 8 83592332
Mobile: 0417 895 244
Email: tom.dunstan@intecgroup.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Macros defined in parsed pages not available on first display
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/3/02 12:07 AM, "Tom Dunstan" <to...@intecgroup.com.au> wrote:
> Hi
>
> I'm experiencing some odd behaviour using Velocity 1.3-rc1 in conjunction
> with struts and the VelocityViewServlet.
>
> In a template which includes another template using #parse, any macros
> defined in the sub-template don't get rendered the first time the page is
> viewed, but appear after that.
>
> Example:
>
> macro.vm:
> #macro(test, $param)
> Macro: param was $param
> #end
>
>
> test.vm:
> #parse("macro.vm")
> #test("blurg")
>
>
> The first time test.vm is viewed, it shows "#test("blurg")", and subsequent
> times shows "Macro: param was blurg", as expected.
>
> Any suggestions?
Yes - the issue is that the #parse() doesn't get executed until runtime,
while the recognition of #<token>( (<arg))* ) is done at parse time - so the
'test' VM doesn't exist until runtime.
I have been musing about doing lazy, runtime determination for
directive-like things, and will see if we can get it in this time around.
geir
>
> Thanks
>
> --
> Tom Dunstan
> Intec Consulting Group
> Tel: +61 8 8359 2332
> Mob: 0417 895 244
> tom.dunstan@intecgroup.com.au
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>