velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <>
Subject Which flavor of Velocity to use?
Date Fri, 26 Dec 2008 22:53:24 GMT
I want to try to port an existing application to Velocity.

This application is in some ways quite like a Web App, yet it is not 
one.  It's user-interface is delivered through the AOL Instant Messenger 
SDK.  In AIM terms, it is a "bot".  Users chat with it as they would 
with any other AIM buddy and it performs various tasks for them, during 
which it presents them with various bits of information.

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> is 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?


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

View raw message