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
