velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: Experiences made by porting a JSP based application to Velocity (with Struts and Tomcat)
Date Fri, 06 Sep 2002 13:24:05 GMT
For self documenting and debugging purposes I used a layout template that
parsed at user option a dump template. See the attachments.

The template processing chain used:
1. At servlet startup load the init.vm template into a its own
    context that is chained into a per request context. This loads
    the skin, colors, tools, etc. Maybe this can now be achieved by the VVS.

2. At every request use a request preprocessing template that loads some
    thread unsafe tools (could be done with the VVS) and does common decoding
    and preprocessing required by the application templates.
    e.g.:
## ------------------------------------------------------------------------
## define request context
## ------------------------------------------------------------------------
#set( $Context  = $Class.newInstance("de.dlr.dfd.naomi.util.ContextTool", $context) )
#set( $Regexp   = $Class.newInstance("org.apache.oro.text.perl.Perl5Util") )
#set( $pp       = $Class.newInstance("de.dlr.dfd.naomi.util.ParameterParser", $req) )
#set( $link     = $Class.newInstance("de.dlr.dfd.naomi.util.DynamicURI", $req, $res) )
#set( $date     = $IsoDate.getDate() )
#set( $log      = [] )
#set( $messages = [] )
#set( $warnings = [] )
#set( $errors   = [] )
## ------------------------------------------------------------------------
## Ensure the session application data cache is valid
## ------------------------------------------------------------------------
#set( $cache = $!session.getAttribute("applicationCache") )
#if( !$cache )
   #set( $cache = $Context.newHashtable(20) )
   #call( $session.setAttribute("applicationCache", $cache) )
#end
#####....some more application specific initialization
## ------------------------------------------------------------------------
## 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 = false )
#set( $debug = $!cache.get("debug") )
#if( !$debug )
   #set( $debug = false )
#end
## overlay the debug flag with possible value from the QueryString
#set( $debug = $pp.getBoolean("debug", $debug) )
## promote the state into the session
#call( $cache.put("debug", $debug) )

3. Process the requested template (the request preprocessing template
    determined in my application the desired template!). This template
    retrieved the variable content data using the pull model.
    An exception would be passed to a error template for presentation.

4. Process the layout template (the requested template could takeover
    the layout, thus skipping this step - useful for presenting textual
    or other content).

That's all!

Note that steps 1 and 2 are application steps under control of the
programmer and not for the page designer, thus does not violate the
MVC pattern!

Charles N. Harvey III wrote:
> [snip]
> 
>>One problem with Velocity is documentation. Of course you can generate
>>JavaDocs out of your business logic classes. But how can you tell a Web
>>Designer, which objects are available where (in which context). The only
>>method I currently know is to write a HTML index page with some
> 
> explanations
> 
>>yourself (manually). Some improvment here would be helpful.
>>
>>Tom
> 
> 
> 
> I was actually working on something like that.  Might take me a while since
> I am really busy at work these days (and I don't even have a computer at
> home
> to save my sanity).  With most xml platforms you can add a request parameter
> and you can see the xml stream so you can see all the variables that are in
> the context.  So I was trying to do the same for Velocity.  Something like:
> 
> Servlet:
> 
> 	ctx.put("context", context);
> 
> 
> Then in VTL (pseudocode):
> 
> 	#foreach ($key in $context.keys)
> 		$key : $context.get($key)
> 		#foreach($class in $key)
> 			$class.getMethods()
> 		#end
> 	#end
> 
> 
> Something like that.  Because Velocity reads all public methods on all the
> classes
> in the context.  So if you can load all the class names and method names
> into
> the context you should then be able to print them out nicely.
> 
> I had imagined it as an extra request parameter like
> /myservlet?showMethods=1.
> So when this is called a certain .vm file is used to display the foreach
> loop
> above.
> 
> If you can get it done faster than me go right ahead.  If I wasn't so busy
> I'm
> sure I could figure it out in a day or two (I'm still new to this java
> stuff).
> 
> Hope this was helpful.
> 
> 
> Charlie
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>
> 
> 

-- 
:) Christoph Reck

Mime
View raw message