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> 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?
It's fairly straight forward to call Velocity outside of any type of
web-app environment:
http://velocity.apache.org/engine/releases/velocity-1.6.1/developer-guide.html#thevelocityhelperclass
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: [email protected]
For additional commands, e-mail: [email protected]
