You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by David Warnock <da...@sundayta.co.uk> on 2001/06/04 15:43:19 UTC

Debug dump context

Hi,

We are working with velocity on a project with separate programmers, 
designers and copywriters.

we are also using sub-templates with #parse a great deal as lots of copy 
is re-used in different places.

Two things would help and I am sure they are possible, it's just I am 
not sure how to do them

1. It would be helpful if we could dump the contents of the context to 
the page. We would have a debug flag set either by the url or from the 
logged in user. When the flag is set we would like the template to 
include in the html the entire context in a table key's on one column 
and values in the other.

Is there a simple way to do this, if not do I write my own object and 
put that in the context or is there a way to write a #foreach that does it?

2. As we are using sub-templates it would be handy to have a way to 
include the current template filename in the output from a template. 
Then again you can turn on debugging and see which .vm template is going 
where so the copy writer knows where to put their text.

Thanks

Dave


Re: Debug dump context

Posted by Brian Leonard <br...@brainslug.org>.
David Warnock <da...@sundayta.co.uk> writes:

> 1. It would be helpful if we could dump the contents of the context to
> the page. We would have a debug flag set either by the url or from the
> logged in user. When the flag is set we would like the template to
> include in the html the entire context in a table key's on one column
> and values in the other.

Put the context in the context, and you could do something like:
#foreach ($item in $context.getKeys())
  $item == $context.get($item) <br>
#end

> 2. As we are using sub-templates it would be handy to have a way to
> include the current template filename in the output from a
> template. Then again you can turn on debugging and see which .vm
> template is going where so the copy writer knows where to put their
> text.

There isn't always just one template per request, so the easiest way
to get this done would be to put the template name in the context.

-bl


Re: Debug dump context

Posted by Dave Warnock <da...@sundayta.com>.
Christoph,

That is all very neat. I am not using turbine but I can easily adapt 
this which is more powerful than the other solutions which I have got 
working.

I particularly like the use of the session for hlding whether debug is on.

I have solved the second part of my problem (showing the start and end 
of each subtemplate) using CVS expansion. So all I need is


#set ($Templatename = "$Source$")
#parse ("StandardTemplateTop.vm")

then the normal template contents

#parse ("StandardTemplateBottom.vm")

The templatetop and bottom as obviously very simple:

#if ($Debug)
Top of $TemplateName<br>
#end



My thanks to all who replied.

Dave


Re: Debug dump context

Posted by Christoph Reck <Ch...@dlr.de>.
I've done this in a usable way (taking the debug from the QueryString
and storing it in the session) by placing the following code snippet
in the request processing file (or in the header of your template or
a template that gets parsed in every top-level template of yours):
##
## ------------------------------------------------------------------------
## Decode dubug flag state
## ------------------------------------------------------------------------
## and save debug flag in session (not in the query string)
## get the debug flag state from the session (false is the default)
#set( $debug = $!req.getSession().getAttribute("debug") )
#if( !$debug )
  #set( $debug = false )
#end
## overlay the debug flag with possible value from the QueryString
#set( $debug = $parameters.getBoolean("debug", $debug) )
## promote the state into the session
#call( $req.getSession().setAttribute("debug", $debug) )
##

The advantage of the above snippet is that you need to enable debug 
only once and then the pages contain the debug trace until it is 
switched off again. You don't need to propagate the debug flag into
generated URLs, and you can switch it on at any time (could be 
restricted by adding an ACL check). 

At the end of the layout template (e.g. turbine) or within any 
template you then use the code from the attachment to pretty print
the context variables:
#if( $debug )
  #parse( "dump.vm" )
#end


Things to note:
1. Due to non-public implementation of the $req.getSession()
   method in tomcat, I've placed a $cache object into the context
   and session within my application servet (VelocityServlet subclass).
   I use $cache.get and $cache.put in the template instead of
   get/setAttribute.
2. The $parameters.getBoolean() is done using an adapted Turbine
   ParameterParser context tool. You could alrternatevly use the
   following code:
     #if( $req.getParameter("debug") == "true" )
       #set( $debug = true )
     #elseif( $req.getParameter("debug") == "false" )
       #set( $debug = false )
     #end
3. The dollar-bang in the $!req.getSession().getAttribute statement 
   uses a registered event cartrige object to supress a log message
   when it is known that the object may be null.
4. I've placed the context itself into the context to be able to 
   dump it.
   I've been thinking of doing a #context directive to do this 
   dynamically:
   #if( $debug )
     #context()
       #parse( "dump.vm" )
     #end
   #end
   But my solution is OK until now. Only of you need the context
   within macros, you may want to implement the #context() directive
   and contribute it to this list.
5. The directive #call is a simple (but *very* usefull) macro:
     #macro( call $foo )#if($foo)#set($dummy=true)#end#end
   which will very silently evaluate the passed parameter, e.g. 
   executing a method and ignoring any result.


Hope this code is helpful,
:) Christoph

David Warnock wrote:
> 
> Hi,
> 
> We are working with velocity on a project with separate programmers,
> designers and copywriters.
> 
> we are also using sub-templates with #parse a great deal as lots of copy
> is re-used in different places.
> 
> Two things would help and I am sure they are possible, it's just I am
> not sure how to do them
> 
> 1. It would be helpful if we could dump the contents of the context to
> the page. We would have a debug flag set either by the url or from the
> logged in user. When the flag is set we would like the template to
> include in the html the entire context in a table key's on one column
> and values in the other.
> 
> Is there a simple way to do this, if not do I write my own object and
> put that in the context or is there a way to write a #foreach that does it?
> 
> 2. As we are using sub-templates it would be handy to have a way to
> include the current template filename in the output from a template.
> Then again you can turn on debugging and see which .vm template is going
> where so the copy writer knows where to put their text.
> 
> Thanks
> 
> Dave

Re: Debug dump context

Posted by Leon Messerschmidt <le...@opticode.co.za>.
> I'm not sure if this circular reference (a reference to the context
> within the context) will screw up some JVMs' garbage collection, so
> I wouldn't recommend doing this in a production system!

Java uses a "mark and sweep" approach for Garbage Collection ( Peter van der
Linden, Just Java 4th edition, p297 ).  The circular reference will probably
not confuse it.  I won't bet large sums of money on it, but it isn't
supposed to be a problem :-)

~ Leon


Re: Debug dump context

Posted by Jeremy Leader <jl...@alumni.caltech.edu>.
At 06:43 AM 6/4/01 , David Warnock wrote:
>Hi,
>
>We are working with velocity on a project with separate programmers, 
>designers and copywriters.
>
>we are also using sub-templates with #parse a great deal as lots of copy 
>is re-used in different places.
>
>Two things would help and I am sure they are possible, it's just I am not 
>sure how to do them
>
>1. It would be helpful if we could dump the contents of the context to the 
>page. We would have a debug flag set either by the url or from the logged 
>in user. When the flag is set we would like the template to include in the 
>html the entire context in a table key's on one column and values in the other.
>
>Is there a simple way to do this, if not do I write my own object and put 
>that in the context or is there a way to write a #foreach that does it?

I imagine in your code somewhere you could do something like:
   context.put("context", context);

and then in your template you could have:

#if ($debug)
   <table>
     #foreach ($key in $context.keys)
       <tr><td>$key</td>
           <td>$context.get($key)</td></tr>
     #end
   </table>
#end

I'm not sure if this circular reference (a reference to the context
within the context) will screw up some JVMs' garbage collection, so
I wouldn't recommend doing this in a production system!

>2. As we are using sub-templates it would be handy to have a way to 
>include the current template filename in the output from a template. Then 
>again you can turn on debugging and see which .vm template is going where 
>so the copy writer knows where to put their text.

I don't know if you can automate this, at one point I just
manually put:

#if ($debug)
   This is file foo.vm
#end

at the top of each of my .vm files.  Actually, I marked the
tops & bottoms of each, which made it much easier to visualize
what Turbine & Velocity were doing.  Once I understood, I was
able to take the debug stuff out.

Jeremy Leader

>Thanks
>
>Dave