velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Byron Foster <>
Subject Re: Which flavor of Velocity to use?
Date Sat, 27 Dec 2008 10:37:06 GMT
On Dec 26, 2008, at 15:53 , Steve Cohen wrote:

> AIM delivers instant messages to our bot, which is implemented using  
> AIM's SDK.  An Instant Message contains of course the text of the  
> IM, which our bot processes much like a command-line parser of a  
> sort.  A properly entered command leads to some sort of action being  
> performed which might be data retrieval or modification, or  
> something else.  An improperly entered command leads to an "error  
> page".  No matter what it is, the feedback to the user is an IM sent  
> back to him via AIM.  Our bot's interface to AIM going in this  
> direction is again the AIM SDK.  This is analogous to a servlet  
> response.
> Additionally, although there are alternatives, AOL's preferred  
> mechanism for receiving inputs from a "bot" is that it be a limited  
> form of xhtml - that is, only a restricted subset of xhtml is  
> allowed.  Things like <b>, <br/>, and <font> are allowed, <table>
> not.  The AIM SDK provides a way of converting strings to this  
> format, but it is not required to use this API.
> Up until now, the relatively simple nature of this interface led me  
> down the primrose path of simply taking strings as input, parsing  
> them, running them through whatever process was required and  
> spitting back out the required output.  I gave no thoughts to MVC.   
> Possible outputs were stored in a properties file, often with  
> various replaceable parameters.  This was easily handled in java,  
> but it's become more cumbersome as the size of this properties file  
> increased.  It got way more cumbersome when I started needing to  
> format the text.  I developed a clever (too clever by half)  
> mechanism for formatting this text using java, but I really need to  
> get away from that.  Java is doing way too much.  I would rather now  
> have a bunch of little "html pages" that have the formatting on  
> them, with the content to be popped in via templating.
> What I want is to have the various boilerplate outputs stored as  
> velocity templates, in an intelligently organized directory tree  
> structure, and use the velocity mechanism to merge in the live  
> data.  Fortunately, even though this application isn't a WebApp, I  
> long ago made the decision to run it inside of Tomcat.  Although it  
> isn't a Web application, there are a couple of minor interfaces that  
> do access the application through servlets, hence Tomcat.  Thus the  
> architecture is all already there to put all the templates under the  
> Web Context root.
> However, as I said, it ISN'T actually a web app.  It doesn't deliver  
> content to users via the http request/response paradigm.  One idea  
> for using velocity in this situation would be to make http://localhost:8080 
>  calls to the Velocity Servlet, get the merged output, read it into  
> a StringWriter, and send that on to the user.  But that doesn't feel  
> right.  It feels like needless overhead.
> I would like to invoke Velocity like a non-webapp, through java, but  
> read the templates from the Web Context as though it were a web  
> app.  Has anyone done anything like that, or otherwise have helpful  
> advice for me?

It's fairly straight forward to call Velocity outside of any type of  
web-app environment:

Since you want to go in the MVC direction you may not want to invoke a  
velocity template directly but maybe reference some sort of logical  
name that refers to a method or class that contains the controller  
logic.  The controller logic would then initialize the context and  
specify the velocity template to render. For example:

public String dispatch(String cntrlName) {
   VelocityContext ctx = new VelocityContext();
   String template;
   if (cntrlName.equals("foo") {
     ctx.put("msg", "this is foo");
     template = "foo.vm";
   else if (cntrName.equals("bar") {
     ctx.put("msg", "this is bar");
     template = "bar.vm";
   else { // Some error}
   StringWriter writer = new StringWriter();
   Velocity.merge(template, "utf-8", ctx, writer);
   return writer.toString();

The above won't compile of course, and the setup is primitive, but you  
get the idea.  If you wanted to hit a velocity page directly you can  
always add the logic for it. So, this is independent of any mechanism  
of providing a request.

You could then create a simple servlet that would map an URL to a  
dispatch cntrlName, call something like above, then stream the result  
to the response.

The above dispatch setup can also be accessed by your AOL SDK front End.

Your templates would generate your XHTML, text or whatever flavor.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message