|
About
Community
Docs
Tools
Comparisons
Site Translations
|
|
Introduction
|
Velocity is a Java-based template engine, a simple and powerful development tool
that allows you to easily create and render documents that format and present
your data. In this guide, we hope to give an overview of the basics of
development using Velocity, focusing on the two main areas for Velocity usage :
- servlet-based WWW development
- general application use
You will see that there is no real difference between these, other than we make
servlet development with Velocity very easy if you use our provided class
VelocityServlet as a base class for your servlet, and offer a utility class to
help with application development.
Getting Started
While this information is found elsewhere on the Velocity site and in the
documentation, it is included here for completeness. Getting Velocity running on
your computer is very easy. Note that all directory references are relative the
root of the Velocity distribution tree.
-
Get the Velocity distribution. This is available as a release, nightly snapshot or
directly from the CVS code repository. Any are fine, although for the latest
features, the nightly snapshot is most likely the best way. For more
information, go here.
-
If you don't have Jakarta Ant,
the Java build tool already installed, please do so. It is required for
building Velocity, although not required for using Velocity.
-
Go to the
build directory in the distribution.
-
Type
ant <build target> where <build target>
is one of:
-
jar builds the complete Velocity jar in the
bin directory. This jar will be called 'velocity-X.jar',
where 'X' is the current version number. This jar does not include
necessary dependencies for Velocity. If you use this
target, you must get the Collections component jar from Jakarta Commons and add
to your CLASSPATH (or WEB-INF/lib).
If you wish to use the built-in logging or template conversion,
you must include the appropriate jars in your CLASSPATH or
webapp's WEB-INF/lib.
For convenience, you can use the jar-dep target to build
a jar with ORO, Logkit and Commons Collections included.
-
jar-dep builds the complete Velocity jar in
the bin directory, including necessary
support for logging from the
Jakarta
Avalon Logkit package, critical configuration support from the
Jakarta Commons
and the necesary support for WebMacro
template conversion using the
Jakarta ORO
package.
-
jar-core builds a slimmer Velocity jar in the
bin directory, called 'velocity-core-X.jar'. This jar
contains the core Velocity functionality, and doesn't include example
and utility things like Anakia, Texen or the VelocityServlet support
baseclass. It has the same external dependency requirements as the
regular jar target.
-
jar-util builds a utility Velocity jar in the
bin directory, called 'velocity-util-X.jar'. This jar
contains utility code, specifically Anakia, Texen, and the WebMacro
template conversion utility. It has the same external dependency requirements as the
regular jar target.
-
jar-servlet builds a utility Velocity jar in the
bin directory, called 'velocity-servlet-X.jar'. This jar
contains utility code for servlet programmers. It has the same external dependency requirements as the
regular jar target.
-
jar-J2EE builds a complete jar, like the 'jar' target,
that includes any components that require J2EE support. Currently, this
includes only org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader.
As usual, it is placed in the bin directory, called
'velocity-j2ee-X.jar'. NOTE : if you wish to use this build target, you
must place (or link) a copy of j2ee.jar into the build/lib directory.
We do not provide it as part of the distribution. A good source is
http://java.sun.com/. It has the same external dependency requirements as the
regular jar target.
-
jar-J2EE-dep build a complete jar with J2EE support
and includes logging support from the Jakarta Avalon Logkit and
regexp support fromt the Jakarta ORO package. See the notes on the
jar-dep target, above.
-
examples builds the example code in the example programs
found in the examples directory. This build target will
also build the forumdemo example project.
-
forumdemo builds the example webapplication in the
examples/forumdemo directory.
-
docs builds these docs in the docs directory
using Velocity's Anakia XML transformation tool.
Allowing you to use
Velocity templates in place of stylesheets
- give it a try! Note: This target requires that the jakarta-site2 project
is located as a peer directory to the jakarta-velocity distribution directory.
Please see the note in the build.xml file for this target for further information.
-
jar-src bundles all the Velocity source code into a single
jar, placed in the bin directory.
-
javadocs builds the Javadoc class documentation in the
docs/api directory
-
test (after jar) will test Velocity against it's testbed
suite of test routines
-
help lists the build targets that are available.
-
While not required, testing the build is a good idea. Use the
test target mentioned above.
-
That's it! Velocity is ready to be used. Put the jar into your classpath, or
into other appropriate places (such as the lib directory of your webapp if
using with servlets)
-
If you want to play with the examples, which is highly recommended when
getting started, use build the examples via
ant examples .
Dependencies
Velocity uses elements of the Java 2 API such as collections, and therefore
building requires the Java 2 Standard Edition SDK (Software Development Kit).
To run Velocity, the Java 2 Standard Edition RTE (Run Time Environment)
is required (or you can use the SDK, of course).
Velocity also is dependent upon a few packages for general functionality. They
are included in the build/lib directory for convenience, but
the default build target (see above) does not include them. If you use the
default build target, you must add the dependencies to your classpath.
|
|
|
Resources
|
There are quite a few resources and examples available to the programmer, and we
recommend that you look at our examples, documentation and even the source code.
Some great sources are :
-
The user and developer community : join us via the
mail-lists.
-
Mail-list archives :
http://www.mail-archive.com is a good one. Type 'velocity' into the search
box to see both our -user and -dev archives.
-
source code :
src/java/... : all the source code to the
Velocity project
-
application example 1 :
examples/app_example1 : a simple
example showing how to use Velocity in an application program.
-
application example 2 :
examples/app_example2 : a simple
example showing how to use Velocity in an application program using the
Velocity application utility class.
-
servlet example :
examples/servlet_example1 : a simple example
showing how to use Velocity in a servlet.
-
logger example :
examples/logger_example : a simple example
showing how to create a custom logging class and register it with
Velocity to receive all log messages.
-
XML example :
examples/xmlapp_example : a simple example
showing how to use JDOM to read and access XML document data from
within a Velocity template. It also includes a demonstration of
a recursive Velocimacro that walks the document tree.
-
event example :
examples/event_example : An example that
demonstrates the use of the event handling API in Velocity 1.1
-
Anakia application :
examples/anakia : example application
showing how to use Velocity for creating stylesheet renderings of xml data
-
Forumdemo web app :
examples/forumdemo : working example of a
simple servlet-based forum application
-
documentation :
docs : all the generated documentation for the
Velocity project in html
-
API documentation :
docs/api : the generated Javadoc
documentation for the Velocity project
-
templates :
test/templates : a large collection of template
examples in our testbed directory, these are a great source of useage
examples of VTL, the Velocity Template Language
-
context example :
examples/context_example : two examples
showing how the Velocity context can be extended. For advanced users.
All directory references above are relative to the distribution root directory.
|
|
|
How Velocity Works
|
'The Fundamental Pattern'
When using Velocity in an application program or in a servlet
(or anywhere, actually), you will generally do the following :
- Initialize Velocity. This applies to both usage patterns for Velocity,
the Singleton as well as the 'separate runtime instance' (see more on this
below), and you only do this once.
- Create a Context object (more on what that is later).
- Add your data objects to the Context.
- Choose a template.
- 'Merge' the template and your data to produce the ouput.
In code, using the singleton pattern via the
org.apache.velocity.app.Velocity class,
this looks like
|
|
|
|
import java.io.StringWriter;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.Template;
import org.apache.velocity.app.Velocity;
import org.apache.velocity.exception.ResourceNotFoundException;
import org.apache.velocity.exception.ParseErrorException;
import org.apache.velocity.exception.MethodInvocationException;
Velocity.init();
VelocityContext context = new VelocityContext();
context.put( "name", new String("Velocity") );
Template template = null;
try
{
template = Velocity.getTemplate("mytemplate.vm");
}
catch( ResourceNotFoundException rnfe )
{
// couldn't find the template
}
catch( ParseErrorException pee )
{
// syntax error : problem parsing the template
}
catch( MethodInvocationException mie )
{
// something invoked in the template
// threw an exception
}
catch( Exception e )
{}
StringWriter sw = new StringWriter();
template.merge( context, sw );
|
|
|
|
|
That's the basic pattern. It is very simple, isn't it? This is generally what
happens when you use Velocity to render a template. You probably won't be
writing code exactly like this - we provide a few tools to help make it even
easier than this for both servlet and application programmers.
Later on in this guide, we will talk about using Velocity in both servlets
as well as general applications, and we discuss the tools we provide to make
things easier. In each case, though, the above sequence is what is happening
either explicitly, or behind the scenes.
|
|
|
To Singleton Or Not To Singleton...
|
As of Velocity 1.2 and later, developers now have two options
for using the Velocity engine, the singleton model and the separate instance
model. The same core Velocity code is used for both approaches, which are
provided to make Velocity easier to integrate into your Java application.
Singleton Model
This is the legacy pattern, where there is only one instance of the Velocity
engine in the JVM (or web application, depending) that is shared by all.
This is very convenient as it
allows localized configuration and sharing of resources. For example, this
is a very appropriate model for use in a Servlet 2.2+ compliant web application
as each web application can have it's own instance of Velocity, allowing
that web application's servlet to share resources like templates, a logger, etc.
The singleton is accessable via the org.apache.velocity.app.Velocity
class, and and example of use :
|
|
|
|
import org.apache.velocity.app.Velocity;
import org.apache.velocity.Template;
...
/*
* Configure the engine - as an example, we are using
* ourselves as the logger - see logging examples
*/
Velocity.setProperty( Velocity.RUNTIME_LOG_LOGSYSTEM, this);
/*
* now initialize the engine
*/
Velocity.init();
...
Template t = Velocity.getTemplate("foo.vm");
|
|
|
|
|
Please note that the Singleton model is used in the
org.apache.velocity.servlet.VelocityServlet base class,
a utility class provided with the distribution to make writing servlets
easier. While extending this class is the most common and convenient
way to write servlets using Velocity, you are free to not use this
class if you needs require something different.
Separate Instance
New in version 1.2, the separate instance allows you to create, configure
and use as many instances of Velocity as you wish in the same JVM
(or web application.) This
is useful when you wish to support separate configurations, such as template
directories, loggers, etc in the same application. To use separate
instances, use the org.apache.velocity.app.VelocityEngine
class. An example, which parallels the above singleton example, looks
like :
|
|
|
|
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.Template;
...
/*
* create a new instance of the engine
*/
VelocityEngine ve = new VelocityEngine();
/*
* configure the engine. In this case, we are using
* ourselves as a logger (see logging examples..)
*/
ve.setProperty( VelocityEngine.RUNTIME_LOG_LOGSYSTEM, this);
/*
* initialize the engine
*/
ve.init();
...
Template t = ve.getTemplate("foo.vm");
|
|
|
|
|
As you can see, this is very simple and straightforward. Except for some simple
syntax changes, using Velocity as a singleton or as separate instances requires
no changes to the high-level structure of your application or templates.
As a programmer, the classes you should use to interact with the Velocity
internals are the org.apache.velocity.app.Velocity class if
using the singleton model, or org.apache.velocity.app.VelocityEngine
if using the non-singleton model ('separate instance').
At no time should an application use the internal Runtime, RuntimeConstants,
RuntimeSingleton or RuntimeInstance classes in the
org.apache.velocity.runtime package, as these are intended for
internal use only and may change over time. As mentioned above,
the classes you should use
are located in the org.apache.velocity.app package, and are the
Velocity and VelocityEngine classes. If anything is
missing or needed from those classes, do not hesitate to suggest changes - these
classes are intended for the application developer.
|
|
|
The Context
|
The Basics
The concept of the 'context' is central to Velocity, and is a common technique
for moving a container of data around between parts of a system. The idea is
that the context is a 'carrier' of data between the Java layer (or you the
programmer) and the template layer ( or the designer ). You as the programmer
will gather objects of various types, whatever your application calls for, and
place them in the context. To the designer, these objects, and their methods
and properties, will become accessable via template elements called
references. Generally, you will work
with the designer to determine the data needs for the application. In a sense,
this will become an 'API' as you produce a data set for the designer to access
in the template. Therefore, in this phase of the development process it is
worth devoting some time and careful analysis.
While Velocity allows you to create your own context classes to support special
needs and techniques (like a context that accesses an LDAP server directly, for
example), a good basic implementation class called VelocityContext is provided
for you as part of the distribution.
VelocityContext is suitable for all general purpose needs, and we strongly
recommended that you use it. Only in exceptional and advanced cases will you
need to extend or create your own context implementation.
Using VelocityContext is as simple as using a normal Java Hashtable class.
While the interface contains other useful methods, the two main methods you
will use are
|
|
|
|
public Object put(String key, Object value);
public Object get(String key);
|
|
|
|
|
Please note that like a Hashtable, the value must be derived from
java.lang.Object, and must not be null. Fundamental types like int or float must
be wrapped in the appropriate wrapper classes.
That's really all there is to basic context operations. For more information,
see the API documentation included in the distribution.
Support for Iterative Objects for
#foreach()
As a programmer, you have great freedom in the objects that you put into the
context. But as with most freedoms, this one comes with a little bit of
responsibility, so understand what Velocity supports, and any issues that may
arise. Velocity supports serveral types of collection types suitable for use
in the VTL #foreach() directive.
-
Object [] Regular object array, not much needs to be said
here. Velocity will internally wrap your array in a class that provides an
Iterator interface, but that shouldn't concern you as the programmer, or the
template author.
-
java.util.Collection Velocity will use the
iterator() method to get an Iterator to use in the loop,
so if you are implementing a Collection interface on your object, please
ensure that iterator() returns a working Iterator.
-
java.util.Map Here, Velocity depends upon the
values() method of the interface to get a Collection
interface, on which iterator() is called to retrieve an Iterator
for the loop.
-
java.util.Iterator USE WITH CAUTION : This is currently
supported only provisionally - the issue of concern is the
'non-resettablity' of the Iterator. If a 'naked' Iterator is placed into
the context, and used in more than one #foreach(), subsequent #foreach()
blocks after the first will fail, as the Iterator doesn't reset.
-
java.util.Enumeration USE WITH CAUTION : Like
java.util.Iterator , this is currently
supported only provisionally - the issue of concern is the
'non-resettablity' of the Enumeration. If a 'naked' Enumeration
is placed into the context, and used in more than one #foreach(),
subsequent #foreach() blocks after the first will fail,
as the Enumeration doesn't reset.
In the case of the Iterator and Enumeration , it is
recommended that they are placed in the context only when it cannot be avoided,
and you should let Velocity find the appropriate reusable iterative interface when
that is sufficient and possible.
There are good reasons to use the java.util.Iterator interface
directly (large data sets via JDBC, for example), but if it can be
avoided, it might be better to use something else. By 'directly' , we meant
doing something like:
|
|
|
|
Vector v = new Vector();
v.addElement("Hello");
v.addElement("There");
context.put("words", v.iterator() );
|
|
|
|
|
where the Iterator itself is placed into the context. Instead, if you
simply did:
|
|
|
|
context.put("words", v );
|
|
|
|
|
then all would be fine: Velocity would figure out that Vector implement
Collection (via List), and therefore will find the iterator()
method, and use that to get a 'fresh' Iterator for its use each time
it needs to. With just a plain Iterator (the first snippet above...),
once velocity has used it in a #foreach() , Velocity has
no way of getting a new one to use for the next #foreach()
it is used in. The result is no output from any subsequent
#foreach() blocks using that reference.
This above isn't meant to give the impression that iterating over
collections in Velocity is something that requires great care and
thought. Rather, the opposite is true, in general. Just be
careful when you place an Iterator into the context.
Context Chaining
An innovative feature of Velocity's context design is the concept
of context chaining. Also sometimes referred to as
context wrapping, this advanced feature allows you to connect
separate contexts together in a manner that makes it appear as one
'contiguous' context to the template.
This is best illustrated by an example :
|
|
|
|
VelocityContext context1 = new VelocityContext();
context1.put("name","Velocity");
context1.put("project", "Jakarta");
context1.put("duplicate", "I am in context1");
VelocityContext context2 = new VelocityContext( context1 );
context2.put("lang", "Java" );
context2.put("duplicate", "I am in context2");
template.merge( context2, writer );
|
|
|
|
|
In the code above, we have set up context2 such that it chains
context1. This means that in the template, you can access any of
the items that were put into either of the two VelocityContext objects,
as long as there is no duplication of the keys used to add objects.
If that is the case, as it is above for the key 'duplicate', the object
stored in the nearest context in the chain will be available. In this
example above, the object returned would
be the string "I am in context2".
Note that this duplication, or 'covering', of a context item does not in
any way harm or alter the covered object. So in the example above, the
string "I am in context1" is alive and well, still accessable via
context1.get("duplicate"). But in the example above, the value of the
reference '$duplicate' in the template would be 'I am in context2',
and the template has no access to the covered string 'I am in context1'.
Note also that you have to be careful when you are relying on the template
to add information to a context that you will examine later after the
rendering. The changes to the context via #set() statements
in a template will affect only the outer context. So make sure that you
don't discard the outer context, expecting the data from the template to
have been placed onto the inner one.
This feature has many uses, the most common so far is providing layered
data access and toolsets.
As mentioned before, the Velocity context mechanism is also extendable,
but beyond the current scope of this guide. If you are interested,
please see the classes in the package org.apache.velocity.context
to see how the provided contexts are put together. Futher, there are a few
examples in the examples/context_example directory in the
distribution which show alternate implementations, including [a goofy] one
that uses a database as the backing storage.
Please note that these examples are unsupported and are there for
demonstration/educational purposes only.
Objects Created in the
Template
There are two common situations where the Java code must deal with objects
created at runtime in the template :
When a template author calls a method of an object placed into
the context by Java code.
|
|
|
|
#set($myarr = ["a","b","c"] )
$foo.bar( $myarr )
|
|
|
|
|
When a template adds objects to the context, the Java code can access
those objects after the merge process is complete.
|
|
|
|
#set($myarr = ["a","b","c"] )
#set( $foo = 1 )
#set( $bar = "bar")
|
|
|
|
|
Dealing with these cases if very straighforward, as there are just a few
things to know:
-
The VTL RangeOperator [ 1..10 ] and ObjectArray ["a","b"] are
java.util.ArrayList objects when placed in the context
or passed to methods. Therefore, your methods that are designed to
accept arrays created in the template should be written with this
in mind.
-
Numbers will be Integers in the context, and strings will be, of course, Strings.
-
Velocity will properly 'narrow' args to method calls, so calling
setFoo( int i ) with an int placed into the
context via #set() will work fine.
Other Context Issues
One of the features provided by the VelocityContext
(or any Context derived from AbstractContext) is
node specific introspection caching. Generally, you as a the developer
don't need to worry about this when using the VelocityContext
as your context. However, there is currently one
known usage pattern where you must be aware of this feature.
The VelocityContext will accumulate intropection information about the
syntax nodes in a template as it visits those nodes. So, in the following
situation:
-
You are iterating over the same template using the same VelocityContext
object.
-
Template caching is off.
-
You request the Template from getTemplate() on each iteration.
It is possible that your VelocityContext will appear to 'leak' memory
(it is really just gathering more introspection information.) What
happens is that it accumulates template node introspection information
for each template it visits, and as template caching is off, it appears
to the VelocityContext that it is visiting a new template each time.
Hence it gathers more introspection information and grows. It is highly
recommended that you do one or more of the following :
- Create a new VelocityContext for each excursion
down through the template render process. This will prevent the accumulation
of introspection cache data. For the case where you want to reuse the
VelocityContext because it's populated with data or objects,
you can simply wrap the populated
VelocityContext in another, and the 'outer' one will accumulate the
introspection information, which you will just discard. Ex.
VelocityContext useThis = new VelocityContext( populatedVC );
This works because the outer context will store the introspection
cache data, and get any requested data from the inner context (as it is empty.)
Be careful though - if your template places data into the context and it's
expected that it will be used in the subsequent iterations, you will need to do
one of the other fixes, as any template #set() statements will be stored in
the outermost context. See the discussion in
Context chaining for more
information.
-
Turn on template caching. This will prevent the template from being re-parsed
on each iteration, resulting the the VelocityContext being able to not only
avoid adding to the introspection cache information, but be able to use it
resulting in a performance improvement.
-
Reuse the Template object for the duration of the loop iterations.
Then you won't be forcing Velocity, if the cache is turned off, to
reread and reparse the same template over and over, so the VelocityContext
won't gather new introspection information each time.
|
|
|
Using Velocity In Servlets
|
Servlet Programming
The most common use of Velocity is in the area of Java Servlet programming
for the WWW. There are many reasons why Velocity is well suited for this
task, one of the primary ones is Velocity's enforcement of the
separation of the presentation (or view) layer from the
code layer. There are many resources on this subject, including
this.
The basic technique of using Velocity in a servlet environment is very simple.
In a nutshell, all you must do is extend the provided VelocityServlet base class
and implement a single method, handleRequest() . That's really all that is
required to use Velocity in your servlet development.
As of Velocity 1.1, there are two handleRequest() methods :
public Template handleRequest( Context )
This is the older of the two methods. This method requires that you
return a valid Template object. If not valid, or null ,
this is considered an error condition, and will result in the error() error
handling method being called. You may override the
error() if you wish. If returning a null is
something you expect to do (for example, you will want to redirect
requests) it is recommended that you use the newer method, listed
next.
public Template handleRequest( HttpServletRequest, HttpServletResponse, Context )
This is the newer of the two handleRequest() methods,
implemented in version 1.1. The difference with this method is that
the HttpServletRequest and
HttpServletResponse objects are passed to you as
arguments to the method, as well as in the Context . The
other difference is that this method can return null to
indicate that all processing has been handled by the method, and that
Velocity should do nothing further than call
requestCleanup() .
This is extremely useful is you wish to redirect the request, for
example.
As always, please refer to the Javadoc API documentation for the definitive and
latest notes.
The following code is similar to the SampleServlet.java class included
in the distribution in the examples directory.
|
|
|
|
public class SampleServlet extends VelocityServlet
{
public Template handleRequest( HttpServletRequest request,
HttpServletResponse response,
Context context )
{
String p1 = "Jakarta";
String p2 = "Velocity";
Vector vec = new Vector();
vec.addElement( p1 );
vec.addElement( p2 );
context.put("list", vec );
Template template = null;
try
{
template = getTemplate("sample.vm");
}
catch( ResourceNotFoundException rnfe )
{
// couldn't find the template
}
catch( ParseErrorException pee )
{
// syntax error : problem parsing the template
}
catch( Exception e )
{}
return template;
}
}
|
|
|
|
|
Look familiar? With the exception of creating the context object, which is
done for you by the VelocityServlet base class, and the merge() step
which is also done for you by the VelocityServlet base class, it's identical
to the basic code pattern we mentioned at the beginning of this guide.
We take the context, add our application data, and return a template.
The default Context object that is passed into the
handleRequest() methods contains both the current
HttpServletRequest and HttpServletResponse
objects. They are placed in the context using the the constants
VelocityServlet.REQUEST (value = 'req') and
VelocityServlet.RESPONSE (value = 'res')
respectively. To access and use these objects in your Java code :
|
|
|
|
public Template handleRequest( Context context )
{
HttpServletRequest request = (HttpServletRequest) context.get( REQUEST );
HttpServletResponse response = (HttpServletResponse) context.get( RESPONSE );
...
|
|
|
|
|
and in your templates:
|
|
|
|
#set($name = $req.getParameter('name') )
|
|
|
|
|
For more advanced uses, the VelocityServlet base class allows you to override
parts of the handling of the request processing. The following methods may
be overridden :
Properties loadConfiguration( ServletConfig )
Allows you to override the normal configuration mechanism and add or
alter the configuation properties. This is useful for overriding or
augmenting template and log paths, to set the absolute path into the
webapp root at runtime.
Context createContext(HttpServletRequest, HttpServletResponse )
Allows you to create the Context object yourself. This allows more advanced
techniques, such as chaining or pre-loading with tools or data. The default
implementation simply returns a VelocityContext object with the request
and response objects placed inside. The request and response objects are
wrapped in simple wrapper classes to avoid introspection problems that may
occurr in some servlet container implementations. You can use the request
and repsponse objects normally, accessing methods of either from the
template. Just note that they aren't specifically javax.servlet.XXXX
classes, if that is important to you.
void setContentType( HttpServletRequest,HttpServletResponse )
Allows you to examine the request and set the content type yourself,
depending on the request or client. The default implementation sets
the content type to be that either specified in the
velocity.properties, if any, or the default, "text/html" if not
specified in the properties.
void mergeTemplate( Template, Context, HttpServletResponse )
Allows you to produce the output stream. The VelocityServlet uses a
pool of very efficient Writer classes, so this would usually be
overridden in special situations.
void requestCleanup( HttpServletRequest,
HttpServletResponse , Context )
Allows you to do any cleanup or resource reclamation at the end of the
request processing. The default does nothing.
protected void error( HttpServletRequest,
HttpServletResponse, Exception )
Error handler that is called an exception occurrs in request
processing. Default implementation will send a simple HTML message
with stacktrace and exception information back to the user. Override
for custom client messages and more advanced problem handling.
For further information, please see the Javadoc
API documentation.
Deployment
When you deploy your Velocity-based servlets, you will certainly want to
ensure that your properties file is used to configure the Velocity runtime.
Under Tomcat, one way to accomplish this is by placing your velocity.properties
file into the root directory of your web app (webapps/appname ) and then
add the following to your WEB-INF/web.xml file :
|
|
|
|
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.foo.bar.MyServlet</servlet-class>
<init-param>
<param-name>properties</param-name>
<param-value>/velocity.properties</param-value>
</init-param>
</servlet>
|
|
|
|
|
Assuming all is right, this will ensure that when MyServlet is loaded,
it will use the velocity.properties file to initialize itself
rather than relying on it's internal defaults.
Note that Velocity uses a singleton model for it's central core Runtime
class, so it is a very good idea to put the velocity-XX.jar
into the WEB-INF/lib directory in all web applications that use
Velocity to ensure that the web app classloader is
managing your Runtime instance, rather than putting it in the CLASSPATH
or the top level lib directory of the servlet runner.
This deployment method will ensure that different web applications will
not be subject to Velocity configuration conflicts.
|
|
|
Using Velocity In General Applications
|
As Velocity was designed to be a general-use tool, it is just as useful in
general application programs as it is servlets. In general, you can use the
same programming pattern discussed at the beginning of this guide, but there
are a few utility methods provided for application use, just like we provide
the VelocityServlet base class for ease of use in servlet programming.
The only new responsibility you have as the application programmer is to
initialize the Velocity runtime engine, but that is easy.
The Velocity Helper Class
Velocity contains an application utility class called Velocity
( org.apache.velocity.app.Velocity ). The purpose of this class
is to provide the necessary methods required to initialize Velocity, as well as
useful utility routines to make life easier in using Velocity. This class is
documented in the project's javadoc, so please look there for definitive
details. This documentation is intended to be of a tutorial nature; therefore
for compete API information, the Javadoc is the definitive source.
The Velocity runtime engine is a singleton instance that provides resource,
logging and other services to all Velocity users running in the same JVM.
Therefore, the runtime engine is initialized only once. You can attempt to
initialize Velocity more than once, but only the first initialization will
apply. The rest of the attempts will be ignored. The Velocity utility
class currently provides five methods used in configuration of the runtime engine.
The five configuration methods are :
setProperty( String key, Object o )
Sets the property key with the value o . The value
is typically a String, but in special cases can also be a comma-separated
list of values (in a single String, ex."foo, bar, woogie") as well as other
things that will arise.
Object getProperty( String key )
Returns the value of the property key. Note that you must be aware of the
type of the return value, as they can be things other than Strings.
init()
Initializes the runtime with the default properties provided in the
distribution.(These are listed below in the section pertaining to
properties.)
init( Properties p ) Initialize the runtime with the
properties contained in the java.util.Properties object passed
as an argument.
init( String filename ) initilizes the runtime
using the properties found in the properties file filename
Note that in each case, the default properties will be used as a base
configuration, and any additional properties specified by the application
will replace individual defaults. Any default properties not overwritten
will remain in effect. This has the benefit that only the properties
you are interested in changing need to be specified, rather
than a complete set.
Another thing to note is that the init() calls may be called
more than once without harm in an application. However, the first call to any
of the init() functions will configure the engine with the
configuration properties set at that point, and any further configuration
changes or init() calls will be ignored.
The most common approaches to initializing Velocity will be something like :
- Setup the configuration values you wish to set in a file in the same
format as org/apache/velocity/runtime/defaults/velocity.properties
(the default set), or in a
java.util.Properties , and then
call either init( filename ) or init( Properties )
- Set the configuration values individually using
setProperty()
and then call init() . This method is generally used by more advanced
applications that already have their own configuration management system -
this allows the application so configure Velocity based upon values it generates
at runtime, for example.
Once the runtime is initialized, you can do with it what you wish.. This mostly
revolves around rendering templates into an output stream, and the Velocity
utility class allows you to do this easily. Currently, here are the methods
and a brief description of what they do :
-
evaluate( Context context, Writer out, String logTag,
String instring )
evaluate( Context context, Writer writer, String logTag,
InputStream instream )
These methods will render the input, in either the form of String or
InputStream to an output Writer, using a Context that you provide.
This is a very convenienient method to use for token replacement of
strings, or if you keep 'templates' of VTL-containing content in a
place like a database or other non-file storage, or simply generate such
dynamically.
-
invokeVelocimacro( String vmName, String namespace, String params[],
Context context, Writer writer )
Allows direct access to Velocimacros. This can also be accomplished
via the evaluate() method above if you wish. Here you
simply name the vm you wish to be called, create an array of args to the VM,
a Context of data, and Writer for the output. Note that the VM args
must be the 'keys' of the data objects in the Context, rather than
literal data to be used as the arg. This will probably change.
-
mergeTemplate( String templateName, Context context, Writer writer )
Convenient access to the normal template handling and rendering services
of Velocity. This method will take care of getting and rendering the
template. It will take advantage of loading the template according
to the properties setting for the file resource loader, and therefore
provides the advantage of file and parsed template caching that Velocity
offers. This is the most efficient way to access templates,
and is recommended unless you have special needs.
-
boolean templateExists( String name )
Determines if a template name is able to be found by
the currently configured resource loaders.
Once we know about these basic helpers, it is easy to write Java program
that uses Velocity. Here it is:
|
|
|
|
import java.io.StringWriter;
import org.apache.velocity.app.Velocity;
import org.apache.velocity.VelocityContext;
public class Example2
{
public static void main( String args[] )
{
/* first, we init the runtime engine. Defaults are fine. */
Velocity.init();
/* lets make a Context and put data into it */
VelocityContext context = new VelocityContext();
context.put("name", "Velocity");
context.put("project", "Jakarta");
/* lets render a template */
StringWriter w = new StringWriter();
Velocity.mergeTemplate("testtemplate.vm", context, w );
System.out.println(" template : " + w );
/* lets make our own string to render */
String s = "We are using $project $name to render this.";
w = new StringWriter();
Velocity.evaluate( context, w, "mystring", s );
System.out.println(" string : " + w );
}
}
|
|
|
|
|
When we run this program, and have the template testtemplate.vm
in the same directory as our program (because we used the default
configuration properties, and the defaul place to load templates
from is the current directory...), our output should be :
|
|
|
|
template : Hi! This Velocity from the Jakarta project.
string : We are using Jakarta Velocity to render this.
|
|
|
|
|
where the template we used, testtemplate.vm, is
|
|
|
|
Hi! This $name from the $project project.
|
|
|
|
|
That's all there is to it! Note that we didn't have to use both
mergeTemplate() and evaluate() in our
program. They are both included there for demonstration purposes.
You will probably use only one of the methods, but depending
on you application requirements, you are free to do what you wish.
This appears to be a little different from the 'fundamental pattern'
that was mentioned at the beginning of this guide, but it really is the
same thing. First, you are making a context and filling it with
the data needed. Where this examples differs is that in the part of
the above example where mergeTemplate() is used,
mergeTemplate() is doing the work of getting the template
and merging it for you, using the lower-level calls in the Runtime class.
In the second example, you are making your template dynamically via the
String, so that is analgous to the 'choose template' part of the process,
and the evaluate() method does the merging for you using
lower level calls.
So the example above sticks to the same simply pattern of using the Velocity
template engine, but the utility functions do some of
the repeated drudge work, or allow you other options for your
template content other than template files.
Exceptions
There are three exceptions that Velocity will throw during the parse / merge cycle.
This are additional to the exceptions that will come from IO problems, etc.
They are found in the package org.apache.velocity.exception and are:
-
ResourceNotFoundException
Thrown when the resource managment system cannot find a resource (template) that
was requested.
-
ParseErrorException
Thrown when a VTL syntax error is found when parsing a resource (template).
-
MethodInvocationException
Thrown when a method of object in the context thrown an exception during
render time. This exception wraps the thrown exception and propogates it
to the application. This allows you to handle problems in your own objects
at runtime.
In each case, a message is put into the runtime log. For more information,
see the Javadoc API documentation.
Miscellaneous Details
While the above example used the default properties, setting your own
properties is very simple. All you have to do is make a properties file
somewhere and pass the name of that file to the init(String)
method of the Velocity utility class, or make a
java.util.Properties object, add the desired properties and
values, and pass that to the init(Properties) method.
The latter method is convenient, because you can either fill it directly
from a separate properties file via the load() method, or even
better, you can fill it dynamically from your own application / framework's
property set at runtime. This gives you the freedom to combine all of the
properties for your app into one properties file.
If we wanted to use a different directory than the current directory to
load our template from, we could do something like this :
|
|
|
|
...
import java.util.Properties;
...
public static void main( String args[] )
{
/* first, we init the runtime engine. */
Properties p = new Properties();
p.setProperty("file.resource.loader.path", "/opt/templates");
Velocity.init( p );
/* lets make a Context and put data into it */
...
|
|
|
|
|
And, assuming you have a directory /opt/templates and the template
testtemplate.vm is in there, then things would work just fine.
If you try this and have a problem, be sure to look at the velocity.log for
information - the error messages are pretty good for figuring out what is wrong.
|
|
|
EventCartridge and Event Handlers
|
Starting in version 1.1, a fine-grain event handling system was added to Velocity.
The EventCartridge is a class in which you register your event handlers, and then the
EventCartridge acts as the delivery agent from which the Velocity engine will
access the event handlers at merge time if needed.
Currently, there are 3 events that can be handled, and all are found in the
org.apache.velocity.app.event package.
org.apache.velocity.app.event.NullSetEventHandler
When a #set() results in a null assignment, this is normally
logged. The NullSetEventHandler allows you to 'veto' the
logging of this condition.
public interface NullSetEventHandler extends EventHandler
{
public boolean shouldLogOnNullSet( String lhs, String rhs );
}
org.apache.velocity.app.event.ReferenceInsertionEventHandler
A ReferenceInsertionEventHandler allows the
developer to intercept each write of a reference ($foo) value to the output
stream and modify that output.
public interface ReferenceInsertionEventHandler extends EventHandler
{
public Object referenceInsert( String reference, Object value );
}
org.apache.velocity.app.event.MethodExceptionEventHandler
When a user-supplied method throws an exception, the
MethodExceptionEventHandler is invoked with the Class, method name
and thrown Exception. The handler can either return a valid Object to be used
as the return value of the method call, or throw the passed-in or new Exception,
which will be wrapped and propogated to the user as a
MethodInvocationException
public interface MethodExceptionEventHandler extends EventHandler
{
public Object methodException( Class claz, String method, Exception e )
throws Exception;
}
Using the EventCartridge
Using the EventCartridge is fairly straightforward. The following abbreviated
example was taken from org.apache.velocity.test.misc.Test .
|
|
|
|
...
import org.apache.velocity.app.event.EventCartridge;
import org.apache.velocity.app.event.ReferenceInsertionEventHandler;
import org.apache.velocity.app.event.MethodExceptionEventHandler;
import org.apache.velocity.app.event.NullSetEventHandler;
...
public class Test implements ReferenceInsertionEventHandler,
NullSetEventHandler,
MethodExceptionEventHandler
{
public void myTest()
{
....
/*
* now, it's assumed that Test implements the correct methods to
* support the event handler interfaces. So to use them, first
* make a new cartridge
*/
EventCartridge ec = new EventCartridge();
/*
* then register this class as it contains the handlers
*/
ec.addEventHandler(this);
/*
* and then finally let it attach itself to the context
*/
ec.attachToContext( context );
/*
* now merge your template with the context as you normally
* do
*/
....
}
/*
* and now the implementations of the event handlers
*/
public Object referenceInsert( String reference, Object value )
{
/* do something with it */
return value;
}
public boolean shouldLogOnNullSet( String lhs, String rhs )
{
if ( /* whatever rule */ )
return false;
return true;
}
public Object methodException( Class claz, String method, Exception e )
throws Exception
{
if ( /* whatever rule */ )
return "I should have thrown";
throw e;
}
}
|
|
|
|
|
|
|
|
Velocity Configuration Keys and Values
|
Velocity's runtime configuration is controlled by a set of configuration keys
listed below. Generally, these keys will have values that consist of either a
String, or a comma-separated list of Strings, referred to as a CSV for
comma-separated values.
There is a set of default values contained in Velocity's jar, found in
/src/java/org/apache/velocity/runtime/defaults/velocity.defaults, that
Velocity uses as it's configuration baseline.
This ensures that Velocity will always have a 'correct' value
for it's configuration keys at startup, although it may not be what you want.
Any values specified before init() time will replace the default values.
Therefore, you only have toconfigure velocity with the values for the keys
that you need to change, and not worry about the rest. Further, as we add more
features and configuration capability, you don't have to change your
configuration files to suit - the Velocity engine will always have default
values.
Please sees the section above Using Velocity In General
Applications for discussion on the configuration API.
Below are listed the configuration keys that control Velocity's behavior.
Organized by category, each key is listed with it's current default value
to the right of the '=' sign.
Runtime Log
runtime.log = velocity.log
Full path and name of log file for error, warning,
and informational messages. The location, if not absolute, is
relative to the 'current directory'.
runtime.log.logsystem
This property has no default value. It is used to give Velocity an
instantiated instance of a logging class that supports the interface
org.apache.velocity.runtime.log.LogSystem. , which allows
the combination of Velocity log messages with your other application
log messages. Please see the section
Configuring the Log System
for more information.
runtime.log.logsystem.class =
org.apache.velocity.runtime.log.AvalonLogSystem
Class to be used for the Velocity-instantiated log system.
runtime.log.error.stacktrace = false
runtime.log.warn.stacktrace = false
runtime.log.info.stacktrace = false
Turns on stacktracing for the three error categories.
These produce a large amount of log output.
runtime.log.invalid.references = true
Property to turn off the log output when a reference isn't valid.
Good thing to turn of in production, but very valuable
for debugging.
runtime.log.logsystem.avalon.logger = name
Allows user to specify an existing logger name
in the Avalon hierarchy
without having to wrap with a LogSystem interface. Note:
You must also specify
runtime.log.logsystem.class =
org.apache.velocity.runtime.log.AvalonLogSystem as the default
logsystem may change. There is no guarantee that the Avalon
log system will remain the default log system.
Character Encoding
input.encoding = ISO-8859-1
Character encoding for input (templates). Using this, you can use
alternative encoding for your templates, such as UTF-8.
output.encoding = ISO-8859-1
Character encoding for output streams from the VelocityServlet and Anakia.
#foreach() Directive
directive.foreach.counter.name = velocityCount
Used in the #foreach() directive, defines the string to be used as the
context key for the loop count. A template would access
the loop count as $velocityCount.
directive.foreach.counter.initial.value = 1
Default starting value for the loop counter reference in a #foreach() loop.
#include() and #parse() Directive
directive.include.output.errormsg.start
=
directive.include.output.errormsg.end
= ]]>
Defines the beginning and ending tags for an in-stream error message in the
case of a problem with the #include() directive. If both the .start and .end
tags are defined, an error message will be output to the stream, of the
form '.start msg .end' where .start and .end refer to the property values.
Output to the render stream will only occur if both the .start and .end
(next) tag are defined.
directive.parse.maxdepth = 10
Defines the allowable parse depth for a template. A template may #parse()
another template which itself may have a #parse() directive. This value
prevents runaway #parse() recursion.
Resource Management
resource.manager.logwhenfound = true
Switch to control logging of 'found' messages from resource manager.
When a resource is found for the first time, the resource name
and classname of the loader that found it will be noted in the
runtime log.
resource.loader = <name> (default = File)
Multi-valued key. Will accept CSV for value. Pulic name of a
resource loader to be used. This public name will then be used
in the specification of the specific properties for that resource loader.
Note that as a multi-valued key, it's possible to pass
a value like "file, class" (sans quotes), indicating that following
will be configuration values for two loaders.
<name>.loader.description
= Velocity File Resource Loader
Description string for the given loader.
<name>.resource.loader.class
= org.apache.velocity.runtime.resource.loader.FileResourceLoader
Name of implementation class for the loader. The default loader
is the file loader.
<name>.resource.loader.path = .
Multi-valued key. Will accept CSV for value. Root(s) from which the
loader loads templates. Templates may live in subdirectories of this root.
ex. homesite/index.vm This configuration key applies currently to the
FileResourceLoader and JarResourceLoader.
<name>.resource.loader.cache = false
Controls caching of the templates in the loader. Default is false, to make
life easy for development and debugging. This should be set to true for
production deployment. When 'true', the modificationCheckInterval
property applies. This allows for the efficiency of caching, with the
convenience of controlled reloads - useful in a hosted or ISP environment
where templates can be modifed frequently and bouncing the application or
servlet engine is not desired or permitted.
<name>.resource.loader.modificationCheckInterval = 2
This is the number of seconds between modification checks when caching is
turned on. When this is an integer > 0, this represents the number of
seconds between checks to see if the template was modified. If the
template has been modified since last check, then it is reloaded and
reparsed. Otherwise nothing is done. When <= 0, no modification
checks will take place, and assuming that the property cache
(above) is true, once a template is loaded and parsed the first time it is used,
it will not be checked or reloaded after that until the application or
servlet engine is restarted.
To illustrate, here is an example taken right from the default Velocity
properties, showing how setting up the FileResourceLoader is managed
|
|
|
|
resource.loader = file
file.resource.loader.description = Velocity File Resource Loader
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path = .
file.resource.loader.cache = false
file.resource.loader.modificationCheckInterval = 2
|
|
|
|
|
Velocimacro
velocimacro.library = VM_global_library.vm
Multi-valued key. Will accept CSV for value.
Filename(s) of Velocimacro library to be loaded when the Velocity
Runtime engine starts. These Velocimacros are accessable to all
templates. The file is assumed to be relative to the root of the
file loader resource path.
velocimacro.permissions.allow.inline = true
Determines of the definition of new Velocimacros via the #macro() directive
in templates is allowed. The default value is true, meaning any template
can define and use new Velocimacros. Note that depending on other properties,
those #macro() statements can replace global definitions.
velocimacro.permissions.allow.inline.to.replace.global = false
Controls if a Velocimacro defind 'inline' in a template can replace
a Velocimacro defined in a library loaded at startup.
velocimacro.permissions.allow.inline.local.scope = false
Controls 'private' templates namespaces for Velocimacros. When true, a #macro()
directive in a template creates a Velocimacro that is accessable only from the
defining template. This means that Velocimacros cannot be shared unless they
are in the global or local library loaded at startup. (See above.) It also means
that templates cannot interfere with each other. This property also allows a technique
where there is a 'default' Velocimacro definition in the global or local library,
and a template can 'override' the implementation for use within that template.
This occurrs because when this property is true, the template's namespace is
searched for a Velocimacro before the global namespace, therefore allowing
the override mechanism.
velocimacro.context.localscope = false
Controls whether reference access (set/get) within a Velocimacro will change
the context, or be of local scope in that
Velocimacro.
velocimacro.library.autoreload = false
Controls Velocimacro library autoloading. When set to true
the source Velocimacro library for an invoked Velocimacro will be checked
for changes, and reloaded if necessary. This allows you to change and
test Velocimacro libraries without having to restart your application or
servlet container, just like you can with regular templates.
This mode only works when caching is off
in the resource loaders (e.g. file.resource.loader.cache = false ).
This feature is intended for development, not for production.
String Interpolation
runtime.interpolate.string.literals = true
Controls interpolation mechanism of VTL String Literals. Note that a VTL
StringLiteral is specifically a string using double quotes that is used
in a #set() statement, a method call of a reference, a parameter to a VM,
or as an argument to a VTL directive in general. See the VTL reference for
further information.
Runtime Configuration
parser.pool.size = 20
This property sets the number of parsers that Velocity will
create at startup and keep in a pool. The default of 20 parsers
should be more than enough for most uses. In the event
that Velocity does run out of parsers, it will indicate
so in the log, and
dynamically create them as needed. Note that they will not
be added to the pool. This is a slow operation compared to
the normal parser pooling, but this is considered an
exceptional condition. If you see a log message, please
increment this property.
Pluggable Introspection
runtime.introspector.uberspect =
org.apache.velocity.util.introspection.UberspectImpl
This property sets the 'Uberspector', the introspection package that
handles all introspection strategies for Velocity. The default works just
fine, so only replace if you have something really interesting and special
to do.
|
|
|
Configuring the Log System
|
Velocity has a few nice logging features to allow both simplicity and
flexibility. Without any extra configuration, Velocity will setup a
file-based logger that will output all logging messages to a file
called velocity.log in the 'current directory' where
Velocity was initialized. For more advanced users, you may integrate
your current logging facilities with Velocity to have all log messages
sent to your logger.
Starting with version 1.3, Velocity will automatically use either the
Jakarta Avalon Logkit logger, or the
Jakarta Log4j logger.
It will do so by using whatever it finds in the current classpath, starting
first with Logkit. If Logkit isn't found, it tries Log4j.
To utilize this feature, simply use the 'non-dependency' Velocity jar
(because Logkit is baked into the jar with dependencies) and place
either the logkit or log4j jar in your classpath.
In general, you have the following logging options :
-
Default Configuration
By default, Velocity will create a file-based logger in the current
directory. See the note above regarding automatic detection of
Logkit or Log4j to use as the default logging system.
-
Existing Log4j Category
Starting with version 1.3, Velocity will log it's output to an existing
Log4j Category setup elsewhere in the application. To use this feature
you must
-
Make sure that the Log4j jar is in your classpath. (You would do this
anyway since you are using Log4j in the application using Velocity.)
-
Configure Velocity to use the
SimpleLog4JLogSystem class.
-
Specify the name of the existing Category to use via the
'runtime.log.logsystem.log4j.category' property.
This approach replaces and deprecates the older Log4JLogSystem
class. To see how this is done in code, see the example below.
-
Custom Standalone Logger
You can create a custom logging class - you simply must implement the
interface org.apache.velocity.runtime.log.LogSystem and
then simply set the configuration property
runtime.log.logsystem.class with the
classname, and Velocity will create an instance of that class at init time.
You may specify the classname as you specify any other properties. See
the information on the
Velocity helper class as well as the
configuration keys and values.
Please note that through oversight, the interface to
org.apache.velocity.runtime.log.LogSystem
was changed in v1.2 to support the separable instances of the Velocity
runtime. If you have an exisiting pre v1.2 custom logger that is going
to be instantiated by the Velocity LogManager, you must add the
init( RuntimeServices ) method.
-
Integrated Logging
You can integrate Velocity's logging capabilities with your applications
existing logging system, simply by implementing the
org.apache.velocity.runtime.log.LogSystem interface. Then,
pass an instance of your logging class to Velocity via the
runtime.log.logsystem configuration key before
initializing the Velocity engine,
and Velocity will log messages to your applications logger.
See the information on the
Velocity helper class
as well as the
configuration keys and values.
Using Log4j With Existing Category
Here is an example of how to configure Velocity to log to an existing Log4j
Category.
|
|
|
|
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.runtime.RuntimeConstants;
import org.apache.log4j.Category;
import org.apache.log4j.BasicConfigurator;
public class Log4jCategoryExample
{
public static String CATEGORY_NAME = "velexample";
public static void main( String args[] )
throws Exception
{
/*
* configure log4j to log to console
*/
BasicConfigurator.configure();
Category log = Category.getInstance( CATEGORY_NAME );
log.info("Hello from Log4jCategoryExample - ready to start velocity");
/*
* now create a new VelocityEngine instance, and
* configure it to use the category
*/
VelocityEngine ve = new VelocityEngine();
ve.setProperty( RuntimeConstants.RUNTIME_LOG_LOGSYSTEM_CLASS,
"org.apache.velocity.runtime.log.SimpleLog4JLogSystem" );
ve.setProperty("runtime.log.logsystem.log4j.category", CATEGORY_NAME);
ve.init();
log.info("this should follow the initialization output from velocity");
}
}
|
|
|
|
|
Note that the above example can be found in examples/logger_example .
Simple Example of a Custom Logger
Here is an example of how to use an instantiation of your class that implements
Velocity's logging system as the logger. Note that we are not passing the name
of the class to use, but rather a living, existing instantiation of the class
to be used. All that is required is that it support the
LogSystem interface.
|
|
|
|
import org.apache.velocity.runtime.log.LogSystem;
import org.apache.velocity.runtime.RuntimeServices;
...
public class MyClass implements LogSystem
{
...
public MyClass()
{
...
try
{
/*
* register this class as a logger
*/
Velocity.setProperty(Velocity.RUNTIME_LOG_LOGSYSTEM, this );
Velocity.init();
}
catch (Exception e)
{
/*
* do something
*/
}
}
/**
* This init() will be invoked once by the LogManager
* to give you current RuntimeServices intance
*/
public void init( RuntimeServices rsvc )
{
// do nothing
}
/**
* This is the method that you implement for Velocity to call
* with log messages.
*/
public void logVelocityMessage(int level, String message)
{
/* do something useful */
}
...
}
|
|
|
|
|
|
|
|
Configuring Resource Loaders
|
Resource Loaders
One of the fundamental and important parts about Velocity is the resource
management system and the resource loaders. They are referred to as 'resources'
here rather than 'templates' because the resource management system will also
handle non-template reasources, specifically things that are loaded via the
#include() directive.
The resource loader system if very flexible, allowing one or more resource
loaders to be in operation at the same time. This allows tremendous
flexibility in configuration and resource managment, and futher allows you
to write your own resource loaders for your special needs.
There are currently four kinds of resource loaders that are included with Velocity,
each described below. Note that in the example configuration properties given,
a common name for the loader is shown
(ex.'file' in file.resource.loader.path ). This 'common name'
may not work for your configuration. Please read the section on
resource configuration properties
to understand how this system works. Also, each of these loaders is
located in the package org.apache.velocity.runtime.resource.loader .
-
FileResourceLoader : This loader gets resources from the filesystem. It's
configuration properties include :
-
file.resource.loader.path = <path to root of templates>
-
file.resource.loader.cache = true/false
-
file.resource.loader.modificationCheckInterval = <seconds between checks>
This is the default loader, and is configured, by default to get templates from the
'current directory'. In the case of using Velocity with servlets, this can be a problem
as you don't want to have to keep your templates in the directory from which you start
your servlet engine. Please see the section on
developing servlets with Velocity
for more information.
-
JarResourceLoader : This loader gets resource from specific jar files. It is very
similar to the FileResourceLoader, except that you have the convenience of bundling
your templates into jars. The properties are identical, except for
jar.resource.loader.path , where you provide the full location of
the jar(s) you wish to load resources from. To specify a jar for the loader.path
you use the standard JAR URL syntax of java.net.JarURLConnection .
-
ClasspathResourceLoader : This loader gets resources from the classloader.
In general, this means that the ClasspathResourceLoader will load
templates placed in the classpath (in jars, for example)
While the
classpath is a source of great pain and suffering in general, it is a very useful
mechanism when working on a Servlet Spec 2.2 (or newer) compliant servlet runner.
Tomcat
is an example of such. To use this loader effectively, all you must do is
jar your templates, and put that jar into the WEB-INF/lib directory of your
webapp. There are no configuration options to worry about, nor is the absolute vs.
relative path an issue, as it is with Jar and File resource loaders.
Again, please note that the ClasspathResourceLoader is not only for use with a
servlet container, but can be used in any application context.
-
DataSourceResourceLoader : This loader will load resources from a DataSource
such as a database. This loader is not built as part of the standard build
as it requires J2EE support. To build this loader, please download the J2EE
distribution, move the j2ee.jar into the
build/lib directory,
and then build the new velocity jar with the jar-j2ee build target.
For more information on this loader, please see the javadoc for the class
org.apache.velocity.runtime.resource.loader.DataSourceResourceLoader .
Configuration Examples
Configuring the resource loaders for Velocity is straightforward.
The properties that control the are listed in the
resource configuration
section, for further reference.
The first step in configuring one or more resource loaders is do
'declare' them by name to Velocity. Use the property
resource.loader and list one or more loader names.
You can use anything you want - these names are used to associate
configuration properties with a given loader.
That entry declares that we will have a resource loader known as 'file'.
The next thing to do is to set the important properties. The most critical
is to declare the class to use as the loader :
|
|
|
|
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
|
|
|
|
|
In this case, we are telling velocity that we are setting up
a resource loadercalled 'file', and are using the class
org.apache.velocity.runtime.resource.loader.FileResourceLoader
to be the class to use.
The next thing we do is set the properties important
to this loader.
|
|
|
|
file.resource.loader.path = /opt/templates
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = 2
|
|
|
|
|
Here, we set a few things. First, we set the path to find
the templates to be /opt/templates . Second, we
turned caching on, so that after a template or static file
is read in, it is cached in memory. And finally, we set
the modification check interval to 2 seconds, allowing Velocity
to check for new templates.
Those are the basics. What follows are a few examples of different configuraitons.
Do-nothing Default Configuration : As the name says, there is nothing
you have to do or configure to get the default configuration. This configuration
uses the FileResourceLoader with the current directory as the default resource
path, and caching is off. As a properties set, this is expressed as :
|
|
|
|
resource.loader = file
file.resource.loader.description = Velocity File Resource Loader
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path = .
file.resource.loader.cache = false
file.resource.loader.modificationCheckInterval = 0
|
|
|
|
|
Multiple Template Path Configuration : This configuration
uses the FileResourceLoader with several directories as 'nodes' on the
template search path. We also want to use caching, and have the templates
checked for changes in 10 second intervals. As a properties set, this is expressed as :
|
|
|
|
resource.loader = file
file.resource.loader.description = Velocity File Resource Loader
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path = /opt/directory1, /opt/directory2
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = 10
|
|
|
|
|
Multiple Loader Configuration : This configuration sets up
three loaders at the same time, the FileResourceLoader,
the ClasspathResourceLoader, and the JarResourceLoader.
The loaders are set-up such that the
FileResourceLoader is consulted first, then the
ClasspathResourceLoader, and finally the JarResourceLoader.
This would allow you to qickly
drop a template into the file template area to replace on of the
templates found in the classpath (usually via a jar) without
having to rebuild the jar.
|
|
|
|
#
# specify three resource loaders to use
#
resource.loader = file, class, jar
#
# for the loader we call 'file', set the FileResourceLoader as the
# class to use, turn off caching, and use 3 directories for templates
#
file.resource.loader.description = Velocity File Resource Loader
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path = templatedirectory1, anotherdirectory, foo/bar
file.resource.loader.cache = false
file.resource.loader.modificationCheckInterval = 0
#
# for the loader we call 'class', use the ClasspathResourceLoader
#
class.resource.loader.description = Velocity Classpath Resource Loader
class.resource.loader.class = org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
#
# and finally, for the loader we call 'jar', use the JarResourceLoader
# and specify two jars to load from
#
jar.resource.loader.description = Velocity Jar Resource Loader
jar.resource.loader.class = org.apache.velocity.runtime.resource.loader.JarResourceLoader
jar.resource.loader.path = jar:file:/myjarplace/myjar.jar, jar:file:/myjarplace/myjar2.jar
|
|
|
|
|
Node that the three names 'file', 'class', and 'jar' are merely for your convenience and
sanity. They can be anything you want - they are just used to associate a set of
properties together. However, it is recommended that you use names that give some hint
of the function.
Note that while all three require very little configuration information
for proper operation, the ClasspathResourceLoader is the simplest.
Pluggable Resource Manager and Resource Cache
The Resource Manager is the main part of the resource (template and static content)
management system, and is responsible for taking application requests for
templates, finding them in the available resource loaders, and then optionally
caching the parsed template. The Resource Cache is the mechanism that the
Resource Manager uses to cache templates for quick reuse. While the default
versions of these two facilities are suitable for most
applications, for advanced users it now is possible
to replace the default resource manager
and resource cache with custom implementations.
A resource manager implementation must implement the
org.apache.velocity.runtime.resource.ResourceManager interface.
A description of the requirements of a resource manager is out of scope for
this document. Implementors are encouraged to review the default implementation.
To configure Velocity to load the replacement implementation, use the
configuration key :
This key is also defined as a contstant
RuntimeConstants.RESOURCE_MANAGER_CLASS
A resource cache implementation must implement the
org.apache.velocity.runtime.resource.ResourceCache interface
As with the resource manager, a description of the requirements of a
resource manager is out of scope for
this document. Implementors are encouraged to review the default implementation.
To configure Velocity to load the replacement implementation, use the
configuration key :
|
|
|
|
resource.manager.cache.class
|
|
|
|
|
This key is also defined as a contstant
RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS
|
|
|
Template Encoding for Internationalization
|
As of version 1.1, Velocity allows you to specify the character encoding of your
template resources on a template by template basis. The normal resource
API's have been extended to take the encoding as an argument :
org.apache.velocity.servlet.VelocityServlet :
public Template getTemplate( String template, String encoding )
org.apache.velocity.app.Velocity :
public static Template getTemplate(String name, String encoding)
public static boolean mergeTemplate( String templateName, String encoding, Context context, Writer writer )
The value for the encoding argument is the conventional encoding specification
supported by your JVM, for example "UTF-8" or "ISO-8859-1". For the official names
for character sets, see here.
Note that this applies only to the encoding of the template itself - the output
encoding is an application specific issue.
|
|
|
Velocity and XML
|
Velocity's flexibility and simple template language makes it an ideal environment
for working with XML data. Anakia is an example of how
Velocity is used to replace XSL for rendering output from XML. The Velocity site,
including this documentation, is generated from XML source using Anakia.
The Jakarta site is also rendered using Anakia.
Generally, the pattern for dealing with XML in Velocity is to use something like
JDOM to process your XML into a data structure with
convenient Java access. Then, you produce templates that access data directly
out of the XML document - directly though the JDOM tree. For example, start
with an XML document such as :
|
|
|
|
<?xml version="1.0"?>
<document>
<properties>
<title>Developer's Guide</title>
<author<EMAIL_ADDRESS>Documentation Team</author>
</properties>
</document>
|
|
|
|
|
Now make a little Java program that includes code similar to:
|
|
|
|
...
SAXBuilder builder;
Document root = null;
try
{
builder = new SAXBuilder( "org.apache.xerces.parsers.SAXParser" );
root = builder.build("test.xml");
}
catch( Exception ee)
{}
VelocityContext vc = new VelocityContext();
vc.put("root", root );
...
|
|
|
|
|
(See the Anakia source for details on how to do this, or the Anakia
example in the examples directory in the distribution.)
Now, make a regular Velocity template :
|
|
|
|
<html>
<body>
The document title is
$root.getChild("document").getChild("properties").getChild("title").getText()
</body>
</html>
|
|
|
|
|
and render that template as you normally would, using the Context
containing the JDOM tree. Of course, this isn't the prettiest of
examples, but it shows the basics - that you can easily access XML data
directly from a Velocity template.
One real advantage of styling XML data in Velocity is that you have
access to any other object or data that the application provides. You
aren't limited to just using the data present in the XML document.
You may add anything you want to the context to provide additional
information for your output, or provide tools to help make working
with the XML data easier. Bob McWhirter's
Werken Xpath
is one such useful tool - an example of how it is used in Anakia can be
found in org.apache.velocity.anakia.XPathTool .
One issue that arises with XML and Velocity is how to deal with XML
entities. One technique is to combine the use of Velocimacros
when you need to render an entity into the output stream :
|
|
|
|
## first, define the Velocimacro somewhere
#macro( xenc $sometext )$tools.escapeEntities($sometext)#end
## and use it as
#set( $sometext = " < " )
<text>#xenc($sometext)</text>
|
|
|
|
|
where the escapeEntities() is a method that does the escaping
for you. Another trick would be to create an encoding utility that takes the
context as a constructor parameter and only implements a method:
|
|
|
|
public String get(String key)
{
Object obj = context.get(key)
return (obj != null) ? Escape.getText( obj.toString() ) : "";
}
|
|
|
|
|
Put it into the context as "xenc". Then you can use it as :
|
|
|
|
<text>$xenc.sometext</text>
|
|
|
|
|
This takes advantage of Velocity's introspection process - it will try
to call get("sometext") on the $xenc object in the Context - then the
xenc object can then get the value from the Context, encode it, and
return it.
Alternatively, since Velocity makes it easy to implement custom Context
objects, you could implement your own context which always applies the
encoding to any string returned. Be careful to avoid rendering the
output of method calls directly, as they could return objects or strings
(which might need encoding). Place them first into the context with a
#set() directive and the use that, for example :
|
|
|
|
#set( $sometext = $jdomElement.getText() )
<text>$sometext</text>
|
|
|
|
|
The previous suggestions for dealing with XML entities came from
Christoph Reck, an active participant in the Velocity community. We are
very grateful for his [unknowing] contribution to this document, and
hope his ideas weren't mangled too badly :)
|
|
|
FAQ (Frequently Asked Questions)
|
In no apparent order, here are questions and answers that repeatedly arise
by developers using Velocity. As we get more, we will move this out to
a separate document.
Why Can't I Access Class Members and Constants from VTL?
The short answer is because we don't introspect for fields. We don't do that
because we wish to promote the idea that you hide your raw data in your
data objects. There are two solutions to this issue. The first is
that you should be writing accessors for data elements you wish to be
publicly exposed. That of course won't work for instances where you don't
have the source, or simply are too lazy. There is a class for the latter
group, org.apache.velocity.app.FieldMethodizer which introspects
your class, and exposes the public static fields in a way that allows easy
access from a template. Suppose you have a class :
|
|
|
|
public class Foo
{
public static String PATH_ROOT = "/foo/bar";
....
}
|
|
|
|
|
Then, in your code, you would put a Foo into the context like this
|
|
|
|
context.put("myfoo", new FieldMethodizer( new Foo() ) );
|
|
|
|
|
Then to access this field in your template, you would simply access in
a manner similar to Java :
If you have a crushing need to access public non-static members (or even private
if you are so driven), then you would have to exend / modify the
FieldMethodizer yourself. (And we still recommend you provide accessors....)
Where does Velocity look for Templates?
By default, without any configuration on your part, Velocity will look
for templates in files, and look for them in the current directory
(or relative to the current directory, if you prepend a path to your
template, like 'foo/bar.vm').
Velocity does this to make it as easy as possible to use out of the box.
It has been argued that Velocity should do it from the 'root' directory, but
it's never clear what that is on filesystems where there are multiple roots
(like - "C:\", "D:\", etc).
For more information, see the section on
resource loaders as well as the section on
configuration keys, values and defaults.
|
|
|
Summary
|
We hope this brief guide was a helpful introduction to using Velocity in
your Java projects, and thank you for you interest in Velocity. We
welcome any and all comments you may have about this documentation and
the Velocity template engine itself.
Please submit all detailed, thoughtful and constructive feedback through our
mail lists.
|
|
|
Appendix 1 : Deploying the Example Servlet
|
A continuing source of frustration for beginning servlet users is getting
all the pieces into place and working. Using a servlet engine like Tomcat or Resin
is far from obvious for the first time user (and even for more experienced users...).
The following are the basic instructions, to the best of our knowledge, for getting
the SampleServlet example working. Note that the sample template sample.vm
and the servlet code itself, SampleServlet.java are
found in the examples/servlet_example directory. Although some servlet
engines (Resin, for example) will compile the servlet for you, it would be best if
you compiled the examples first. To do this, see the section on building Velocity, and
use the examples target.
Jakarta Tomcat
Setting up under Jakarta Tomcat is fairly
straightforward. The 'webapp' directory is where Tomcat automatically
looks for it's 'web applications', so
this is where we will set things up.
- First, make a new 'webapp' by creating a directory called velexample
in Tomcat's webapps directory, and make
a new directory structure as follows :
velexample
velexample/WEB-INF
velexample/WEB-INF/lib
velexample/WEB-INF/classes
-
Put the Velocity jar into the velexample/WEB-INF/lib directory. Note that with v1.2
and newer, you either have to either use the jar from the distribution (or that you
build yourself) that contains all the dependencies ( ex. velocity-dep-1.2.jar) or
you must add the dependency jars yourself to the WEB-INF/lib directory. Please see
the section "Getting Started" and "Dependencies", above.
-
Put the SampleServlet.class into the velexample/WEB-INF/classes directory
-
Put the sample.vm template into the velexample directory. The SampleServlet is
written to use the root of the webapp as the source of the templates, so
no configuration is needed.
-
At this point, you should be able to start (or restart) Tomcat and access the servlet.
-
To access the servlet, point your web browser at :
http://localhost:8080/velexample/servlet/SampleServlet
or if that doesn't work :
http://<your computer's ip address>:8080/velexample/servlet/SampleServlet
-
You should see the sample output.
Caucho Technology's Resin
Setting up the example servlet under Caucho Technology's Resin
servlet engine is also very simple. The following instructions were tested with the version 1.2.5
release. The following assume that you have unzip-ed or untar-ed the distribution, know how to start
the servlet engine (something like bin/httpd.sh under unix...), and know where the doc directory is
(in the root of the distribution).
-
Copy the SampleServlet.class file into the doc/WEB-INF/classes directory.
-
Copy the sample.vm template file into the doc/ directory
-
Copy the Velocity jar (and any required dependencies - see note above in
Tomcat setup section) into the doc/WEB-INF/lib directory.
-
Start resin.
-
To access the servlet, point your web browser at :
http://localhost:8080/servlet/SampleServlet
or if that doesn't work :
http://<your computer's ip address>:8080/servlet/SampleServlet
and you should see the output.
Note that this appeared to be a simpler configuration - with the Tomcat example,
you set up a complete, new, separate webapp, whereas the Resin instructions
don't, although both should provide a sufficient setup to let you play with
Velocity.
Note that while we wish we could, we can't answer questions about the servlet
engines. Please use the resources provided by the servlet engine provider.
BEA WebLogic
Paw Dybdahl<EMAIL_ADDRESS>contributed this
description of using Velocity with WebLogic, as well as some good general suggestions and
examples for working with servlets.
|
|
|


Welcome to Electron app running on this magnificent machine.
App author:
Environment:
Electron version:
Directorio:


Wandoo Reader
Helping to make summer reading at the library fun and easy
Wandoo Reader is a gamified reading program management tool designed for librarians who want a simple and fun way to encourage literacy in their communities, and track engagement data for their programs.
Project Overview
The Challenge
Evanced's market leading summer reading product was quickly gaining a reputation for being archaic and difficult to use. The aging platform was unable to keep up with the evolving needs of librarians and library patrons.
My Role
As the lead UX designer on the project I was involved from kickoff to launch, even pitching multiple product features and seeing them through to production.
The Team
The project team included a front end designer, a product owner, a subject matter expert in the field of children's education, and a development team located in Leeds England (Dubit).
Discovery
Getting out of the building
We put our initial assumptions to the test by visiting libraries in 5 states and listening to the frustrations and fantasies librarians had about their summer reading programs. These interviews helped us understand where our current product fell short and informed of our user personas.
"The summer reading software we use is very intensive to set up.
I had to figure out HTML code to make changes."
"Keeping track of paper logs is a lot of work for our staff,
especially when we have to turn in our yearly reports."
"Our library creates a huge, elaborate game board that goes
along with our summer reading program."
Learning from social media
As part of our research, we followed librarians on social media platforms like twitter, reddit, and tumblr. We weren't surprised to find that librarians are fantastic writers and communicators. Find more hilarious librarian problems here.
Ideation and Prototyping
I worked very closely with the product owner throughout the project with near daily white boarding sessions to define requirements and sketch out ideas. After each iteration of the design, we tested with librarians and library patrons.
Ultimately we designed an experience that allowed library patrons to track their reading, complete challenges, win awards, and receive messages from the library.
Beyond just summer "reading"
Research shows that students lose an average of 2-3 months of academic skills during the summer months including math and science. That is why libraries are broadening their definition of summer reading to include STEM, physical activity, and fun.
As a first step toward summer learning, I designed a customizable challenge that allowed librarians to design challenges to be completed by patrons using the website. Most librarians are naturally creative and loved thinking up challenges, while patrons enjoyed seeing new content pop up when they logged in to Wandoo Reader.
It was incredible to see this feature catch fire quickly after launch with 4,198 challenges created by librarians and 122,683 completed by patrons in the first summer season it was launched.
Designing for children
I worked with a very talented subject matter expert and former teacher to test designs and be sure that all copy on the site was an appropriate grade level for the audience. We did this by conducting a pilot with three different schools and ongoing interviews with kids and teacher librarians from those schools.
We ended up adding special features for the kid's version of the product including a new theme and story each year, and the ability to level up and customize a character.
What I would have done differently
Looking back, we had data to suggest that kids were using mobile devices more and more each year. We treated desktop as the primary use case, therefore the mobile experience - navigation especially - could use some improvement. There was also a huge need for a Spanish version of the product, which did not make the cut for our first release. If I could go back I would definitely have fought to get that feature prioritized.


node-sass-package-importer
Custom importer for node-sass to import packages from the node_modules
directory.
Usage
In modern day web development, packages are everywhere. There is no way around npm if you are a JavaScript developer. More and more CSS and SASS projects move to npm but it can be annoying to find the correct way of including them into your project. Package importing makes this a little easier.
var sass = require('node-sass');
var packageImporter = require('node-sass-package-importer');
sass.render({
...
importer: packageImporter
...
});
// Import the file that is specified in the `package.json` file of the module.
// In the case of bootstrap, the following file is loaded:
// https://github.com/twbs/bootstrap/blob/v4-dev/scss/bootstrap.scss
@import '~bootstrap';
// Import only specific files:
@import '~bootstrap/scss/variables';
@import '~bootstrap/scss/mixins/border-radius';
@import '~bootstrap/scss/mixins/alert';
@import '~bootstrap/scss/alert';
The "~" is optional, it is a hint for developers that this is a module path.
Path resolving
If only the module name is given (e.g. @import '~bootstrap'
) the importer looks in the package.json
file of the module for the following keys: "sass", "scss", "style", "css", "main.sass", "main.scss", "main.style", "main.css" and "main". The first key that is found is used for resolving the path and importing the file into your sass code.
To load only a certain file from a module you can specify the file in the import url (e.g. @import '~bootstrap/scss/_alert.scss'
). This module also supports partial file name resolving so you can import files by only specifying their base name without prefix and extension (e.g. @import '~bootstrap/scss/alert'
). Sadly bootstrap and most other frameworks do not load their dependencies directly in the concerned files. So you have to load all dependencies of a file manually like in the example above. I recommend you to do better and to import dependencies directly in the files that are using them.
Options
In the example below you can see the default configuration options.
cwd
: Defines the path in which yournode_modules
directory is found.extensions
: Set which file extensions should get resolved.packageKeys
: You can define thepackage.json
keys to search for and in which order.
var sass = require('node-sass');
var packageImporter = require('node-sass-package-importer');
sass.render({
...
importer: packageImporter,
packageImporter: {
cwd: process.cwd(),
extensions: [
'.scss',
'.sass'
],
packageKeys: [
'sass',
'scss',
'style',
'css',
'main.sass',
'main.scss',
'main.style',
'main.css',
'main'
]
}
...
});
CLI
node-sass --importer node_modules/node-sass-package-importer -o dist src/index.scss
node-sass-magic-importer
This module is part of the node-sass-magic-importer module.
About
Author
Markus Oberlehner
Twitter: https://twitter.com/MaOberlehner
License
MIT


Exam hall timer by Paul Baumgarten 2019pbaumgarten.com
The link below will pre-load the page with these exam details


Jessica Erin Dempsey
Unafffiliated
Account Development Specialist Breakthru Beverage Colorado
B.A. Political Science, B.A. Geography; Environmental Studies
80207
I am an active and engaged voter. I have never missed an election in Colorado where I have been voting for 25 years. In the past ten years I have donated either time or nominal financial amounts to Planned Parenthood, NARAL, Obama, Clinton and Biden campaigns. I have also contributed to the SOS Denver campaign to save the Park Hill Golf Course from a dissolution of the protective environmental easement.
Overlook at Park Hill Neighborhood Association, Park Hill Elementary PTSA, Women of Denver. SOS Denver.
My first introduction to organizing and advocacy was during an internship with NARAL Pro Choice Colorado during college. Through this internship I gained insight to how bills are drafted, heard and ultimately voted upon in the State Legislature. I learned how to mobilize constituents and connect them with their representatives to make their voices heard. In recent years organizational volunteer work is centered around my neighborhood and my child's school. Though the size, scope and goals are quite different much of the process is the same. This includes gathering, listening and actual hearing input from neighbors, other parents and members of our community on the things that are the most important to them. Followed by complete and careful analysis and problem shooting.
I have long wanted to contribute to the city, state and community in which I live in a more meaningful way. I believe with the new laws that we as citizens passed in 2018 regarding an overhaul of the redistricting process we have said we want regular people, members of the community, to have a role. While I understand that an overhaul of this system is an immense undertaking I believe it is necessary in order to create a system and ultimately a map that is fair and does not give the power to draw the map to the very people seeking power. The responsibility for reform falls on the voters who approved the Amendments Y and Z. I am one of those voters and believe I can be fair and impartial when making decisions.
By my very nature I am a mediator. I believe the best qualities one can have to create consensus are patience, listening skills, compassion, rationality, empathy and optimism. It is important to understand when something isn't practical even though you'd really like it to be. I believe it is useful to not be quick to anger. Compromise is difficult when emotions are running high. I do believe I possess a good balance of feeling with pragmatism.
Analyzing data is a large part of my job currently. Though the data I look at is different I believe I possess the analytical skills to look at, absorb and understand what that data represents. I have excellent critical thinking skills that immediately lend themselves to problem solving. Once a problem has been determined, the logical next step in my mind is to explore solutions. Above all I believe I am a logical person. Being able to see both sides of a conflict equally and at times help those involved see another point of view is something that has always come rather naturally to me. I do not think this process can happen successfully with out that type of compromise.
Female


Need to reach me? Stop by and say hi!
Github LinkedIn
Google Scholar
Location: Pasadena, CA
Email:
Homepage: Return to the homepage.
Beckman Auditorium, Caltech


User can get the IP address, preferred languages (from header Accept-Language)
and system infos (from header User-Agent) for his device.
{"ipaddress":"<IP_ADDRESS>","language":"en-US,en;q=0.5",
"software":"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0"}
Made with by Suresh Mangs


This example demonstrates the usage of ThermodynamicDiagramPluggable
.
Each part of the diagram is seperatly constructed (Classes:
xAxis
,
yAxis
,
TDDiagram
,
WindbarbsProfile
,
WindspeedProfile
,
Hodograph
).
Additionally a ϴe diagram is constructed. On the one hand a diagram with the
Stüve coordinate system
is used. Otherwise the diagram object is adjusted, how a sounding is plotted.
This could be achieved with the constructor options
dataGroupIds
, getCoordinatesByLevelData
, insertDataGroupInto
.
The snowfall limit line is plotted with the usage of the postbuild:background
event.
Sounding data source: weather.uwyo.edu


In this example a folder tree is created with different types of file system objects: folders, files and links.
On UNIX each object is associated with a structure called the i-node, this reference is in the folder entries where the objects are.
The links refer to other objects, and are associated with the same i-node of the object to which they relate, i-nodes keep track of objects associated with them.
Reminder 1: the folders' color is green and the links are blue. The files color is defined when created.
Reminder 2: In the simulation the folder size is 1 block, while the links do not occupy disk space, they are simply entries in its folder data.
Reminder 3: The structure of an i-node is
| Tree | Type | Size Units |
|||
| / | Folder | 1 | |||
| folder1 | Folder | 1 | |||
| file1.txt | File | 101 | |||
| file2.txt | File | 200 | |||
| link1 | Hard link (to file1.txt) |
1 | |||
| folder2 | Folder | 1 | |||
| file3.txt | File | 460 | |||
| Folder3 | Folder | 1 | |||
| file4.txt | File | 120 | |||
| link2 | Hard link (to link1) |
0 |
Block size is 1 unit.
Comments: