Velocity vs. XMLC

[Christopher Cain <cc...@mhsoftware.com>]

Hey buddy.

First of all, thanks for the nod on getting committer status. Nothing
has happened yet, and I e-mailed Craig privately to get his thoughts on
whether he favors the idea or not. I haven't heard back yet, but I know
he's a busy man. I'm sure at some point that my PATCHES assult will
become annoying enough to either give me access or tell me to bugger off
=)

Actually, the real reason I'm hitting you up is to get an expert opinion
on Velocity. I'm far from a presentation-layer expert, as most of our
clients want custom web database apps for line-of-business type stuff.
We therefore usually just build database-aware Java middleware objects
and use servlets. Servlets aren't exactly the coolest technology for the
presentation layer, but we're a small shop with only a few developers,
so it's not like we're handing off the page design piece to
HTML-monkeys. I can just slam out serious business apps and call my
middleware directly from front-end servlets. It's fast and easy for our
particular environment.

As far as customers wanting to tweak the look and feel of the site, we
created a pretty cool little database-driven CSS generator and hooked a
simple web-based front-end to it. You can add/edit/delete HTML tags,
assign applicable attributes to each tag, and assign predefined values
for each attribute (or allow freeform value assignment). You can even
save x number of named stylesheets use any stylesheet for any given
page. It got us out of the "Can you make the background a little more
blue" business, and customers can go in and tweak the look-and-feel to
their hearts content.

Anyway, we now have a customer with a hellishly complex app, and they
also want to control the general app execution to the extent that we can
let them. Stuff like, "we want to change the menu link which calls the
blah-de-blah validator to be a button near the top," "we want the POST
of page A to call page B before it calls page C" ... stuff like that.
Sounds like a job for Velocity, in my opinion: they can construct their
application own flow and call out to our heavy-hitting data objects and
methods for the real app execution.

My boss is a very bright man, and he's hated JSP pretty much as long as
you have. Thankfully, I don't even have to HAVE that discussion. Since
I'm heavily involved in Jakarta, I immediately thought of Velocity. He's
a _real_ Tomcat supporter, but he doesn't have alot of experience with
the rest of the Jakarta world, and as a result he's never heard of
Velocity. I've explained it to him, and he thinks it sounds pretty cool.
He had also read about a product in the latest Linux Journal, from
Enhydra, called XMLC (which honestly, *I* had never heard of). I read up
on it, and it sounds pretty cool too. Maybe it's because I a Jakarta
zealot, or maybe it's just because I'm naturally skeptical of power
users writing properly-formatted XHTML, but I still prefer Velocity. So
as the inventor/lead of Velocity, what do you see as the major benefits
of Velocity over XMLC in a power user environment? We're not talking
about a company who has an IT department, we're talking about a company
who has a resonably-savvy HTML page static designer ... kind of a
glorified pixel mechanic with enough skill in straight HTML to contract
a web page from scratch, but no real programming experience to speak of.

I'm looking for some counterpoints that I can take to the boss, from
someone alot more knowledgable in the field than I am. He's an Open
Source guy through-and-through, a Linux cat from the old school days,
and I'm actually damn fortunate that selling my boss on a technology is
like a trip to Disneyland compared to what you have to do in the
corporate world. He's primarily concerned about two things: Getting a
technology in place that these guys will have the most trouble screwing
up and/or whining about its complexity, and the one that they will have
the most trouble screwing US with, like crashing their own server and/or
calling out our processing objects when they shouldn't. We realize that
both of these are inevitable, but we're looking for the path of least
resistance. These guys need something as dummy-proof as is possible,
because the whole idea is to reduce the amount of calls we get on
semanic pixel-pushing nonsense when we're busy trying to code complex
application processing and database transactions to meet their _actual_
business needs. You know how it is.

Anyway, if you get a spare minute (no rush, the project is at least a
week out), I just wanted to get some ammo for Velocity. I mean, this
XMLC shit sounds like a decent enough solution I guess ... in a
well-oiled corporate IT environment. It sounds like a headache waiting
to happen in our case, though.

Thanks!

- Christopher

Re: Velocity vs. XMLC

[Christopher Cain <cc...@mhsoftware.com>]

Ooops ... this was meant to go to Jon privately!!! (That reply-to header
gets me every time =)

DAMN!!!

Oh well, good thing I didn't bust on any of you guys or anything =)

Anyway, I guess since I accidentally sent it (believe me, I PROMISE it
was accidental and not a troll for OT comments), if anyone feels like
PRIVATELY (off-list) giving me their thoughts on Velocity vs. XMLC, feel
free.

Otherwise, feel free to just delete this renegade mail and go on about
your day :-)

- Christopher

Christopher Cain wrote:
> 
> Hey buddy.
> 
> First of all, thanks for the nod on getting committer status. Nothing
> has happened yet, and I e-mailed Craig privately to get his thoughts on
> whether he favors the idea or not. I haven't heard back yet, but I know
> he's a busy man. I'm sure at some point that my PATCHES assult will
> become annoying enough to either give me access or tell me to bugger off
> =)
> 
> Actually, the real reason I'm hitting you up is to get an expert opinion
> on Velocity. I'm far from a presentation-layer expert, as most of our
> clients want custom web database apps for line-of-business type stuff.
> We therefore usually just build database-aware Java middleware objects
> and use servlets. Servlets aren't exactly the coolest technology for the
> presentation layer, but we're a small shop with only a few developers,
> so it's not like we're handing off the page design piece to
> HTML-monkeys. I can just slam out serious business apps and call my
> middleware directly from front-end servlets. It's fast and easy for our
> particular environment.
> 
> As far as customers wanting to tweak the look and feel of the site, we
> created a pretty cool little database-driven CSS generator and hooked a
> simple web-based front-end to it. You can add/edit/delete HTML tags,
> assign applicable attributes to each tag, and assign predefined values
> for each attribute (or allow freeform value assignment). You can even
> save x number of named stylesheets use any stylesheet for any given
> page. It got us out of the "Can you make the background a little more
> blue" business, and customers can go in and tweak the look-and-feel to
> their hearts content.
> 
> Anyway, we now have a customer with a hellishly complex app, and they
> also want to control the general app execution to the extent that we can
> let them. Stuff like, "we want to change the menu link which calls the
> blah-de-blah validator to be a button near the top," "we want the POST
> of page A to call page B before it calls page C" ... stuff like that.
> Sounds like a job for Velocity, in my opinion: they can construct their
> application own flow and call out to our heavy-hitting data objects and
> methods for the real app execution.
> 
> My boss is a very bright man, and he's hated JSP pretty much as long as
> you have. Thankfully, I don't even have to HAVE that discussion. Since
> I'm heavily involved in Jakarta, I immediately thought of Velocity. He's
> a _real_ Tomcat supporter, but he doesn't have alot of experience with
> the rest of the Jakarta world, and as a result he's never heard of
> Velocity. I've explained it to him, and he thinks it sounds pretty cool.
> He had also read about a product in the latest Linux Journal, from
> Enhydra, called XMLC (which honestly, *I* had never heard of). I read up
> on it, and it sounds pretty cool too. Maybe it's because I a Jakarta
> zealot, or maybe it's just because I'm naturally skeptical of power
> users writing properly-formatted XHTML, but I still prefer Velocity. So
> as the inventor/lead of Velocity, what do you see as the major benefits
> of Velocity over XMLC in a power user environment? We're not talking
> about a company who has an IT department, we're talking about a company
> who has a resonably-savvy HTML page static designer ... kind of a
> glorified pixel mechanic with enough skill in straight HTML to contract
> a web page from scratch, but no real programming experience to speak of.
> 
> I'm looking for some counterpoints that I can take to the boss, from
> someone alot more knowledgable in the field than I am. He's an Open
> Source guy through-and-through, a Linux cat from the old school days,
> and I'm actually damn fortunate that selling my boss on a technology is
> like a trip to Disneyland compared to what you have to do in the
> corporate world. He's primarily concerned about two things: Getting a
> technology in place that these guys will have the most trouble screwing
> up and/or whining about its complexity, and the one that they will have
> the most trouble screwing US with, like crashing their own server and/or
> calling out our processing objects when they shouldn't. We realize that
> both of these are inevitable, but we're looking for the path of least
> resistance. These guys need something as dummy-proof as is possible,
> because the whole idea is to reduce the amount of calls we get on
> semanic pixel-pushing nonsense when we're busy trying to code complex
> application processing and database transactions to meet their _actual_
> business needs. You know how it is.
> 
> Anyway, if you get a spare minute (no rush, the project is at least a
> week out), I just wanted to get some ammo for Velocity. I mean, this
> XMLC shit sounds like a decent enough solution I guess ... in a
> well-oiled corporate IT environment. It sounds like a headache waiting
> to happen in our case, though.
> 
> Thanks!
> 
> - Christopher