Jonathan Revusky <[EMAIL PROTECTED]> writes:
> Daniel Rall wrote:
> > 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.
This apples to apples comparisons is a natural first step, and
provides solid examples. An apples to zucchini comparison is also
helpful, since the use cases which don't fit a model are the ones
which cause its users the most trouble.
I ran through a few such comparisons, and a Map-based context handles
all use cases for the input processing step (objects are simply
gloried hashtables). One doesn't always want to involve character
encodings in content generation (e.g. for binary output), so using a
generic Object interface for output is preferred to coupling the API
to Writer. This also handles output of more complex types (e.g. DOM
trees, etc.).
public interface ContentGenerationSystem
{
/**
* Performs content generation, converting its inputs to the
* appropriate CGS-specific types.
*
* @param context Contextual information used as inputs to the
* content generation system. May be <code>null</code>.
* @param target The target to generate content for. May be
* <code>null</code> if <code>context</code> contained sufficient state.
* @param output Where to send the generated content.
*/
void generateContent(Map context, String target, Object output);
}
If multiple output types are supported, generateContent() can use the
instanceof operator to choose the appropriate action.
...
> 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.
Personally, I'd be very happy to see FreeMarker available in Turbine
again, so long as its integration is supported by an active developer.
The original reason it was dropped was a lack of both developer
support and user interest.
I'd be even more happy to see a light-weight content generation
abstraction (something like what's outlined above), replacing what's
in Turbine 3.
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
