I'd like to point out the generic context implementation already exists in the TemplateService in Fulcrum, and is used in Turbine 3 (and thus in Scarab). I urge you not to give specifics of a generic context path even a moment's consideration, as doing so adds needless complexity and offers very little in return.
Any movement towards a generic context interface should use an opaque type, like Object or an empty marker interface (from what I saw of the recent TorqueComponent impl., Avalon uses these to good effect). Content rendering engines are inherently different, and pretending that they are does not make them so (read: don't fool yourself). Each individual rendering system will do the appropriate thing with its contextual argument.
From my experience, I think you can basically say that any Context object is a hashtable of some sort. So, it is probably feasible just to use java.util.Map and, if necessary, convert the Map into the concrete class when needed in the concrete implementation. The whole thing looks quite trivial.
// in Velocity-specific concrete class, approximately:
void processTemplate(Map someMap, String templateLocation, Writer out) {
VelocityContext vc = new VelocityContext(someMap);
Template t = Velocity.getTemplate(templateLocation);
Velocity.mergeTemplate(templateLocation, vc, out);
}// in FreeMarker-specific concrete class, you just use the Map directly // since the conversion from the Map object occurs transparently.
void processTemplate(Map someMap, String templateLocation, Writer out) {
Template t = Configuration.getTemplate(templateLocation);
t.process(someMap, out);
}I mean, the fundamental pattern of usage is just so similar that abstracting it out and simply using whatever template engine from a common API is really quite a trivial exercise.
Now, okay, there are always minor niggling details. For example, Anthony Eden had some various things in JPublish where he wanted to have some special location strings for loading templates, because JP has this notion of a "repository" and so on. And actually I ended up tweaking some things in FreeMarker to support things he wanted to do -- so that includes and things could work with his special template location URI's. Sure, things like this come up and it is good to have the active collaboration of the developers of the other system that you want to glue to...
But anyway, if you guys get your house in order to the point where you don't have all these points of coupling with classes in org.apache.velocity.*, then I'll do whatever incremental work is necessary to make sure that FM works there on an even footing.
As I said, the current state of things is that it's not feasible because of all the various coupling points. For this to fly, there has to be a clearly documented common API for getting at the services oif a template engine, and it should be just 2 or 3 subclassing points, I would say, and the rest of the framework should use template engine services via that API.
Until you have such a situation, it is pointless to tell me or somebody else in my position: "Submit a patch." and so on, because you don't have your house sufficiently in order to where somebody could really do that.
Now, there clearly is interest on the part of some users to be able to try FM from Turbine. I've seen signs of that on this list and I have some private email that bears this out. So my earlier offer still stands: Get your house in order on this stuff, and I'll help you get it working. But the ball is currently in your court on this.
Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
