[Web-SIG] Standardized template API

[Phillip J. Eby]

At 06:08 PM 2/3/2006 -0500, Michael Bayer wrote:
>Phillip J. Eby wrote:
> > What I'd suggest is that this is actually an opportunity for Myghty to put
> > its lookup and caching on one side of the interface, and an actual
> > template
> > rendering facility on the other side.  That is, treat Myghty as an
> > embedd*er* rather than the embedd*ee*, so that the engine can be used with
> > arbitrary apps or templates on the embedded side.
> >
> > I'm not really familiar with Myghty, though, so I might not be saying
> > something sensible here.  I'm just saying that if you have a mechanism for
> > locating, compiling, and caching templates, then it should live on the
> > framework side of the "engine" interface.  An embedding engine offers the
> > "compile_string, compile_stream, write_compiled, read_compiled" methods,
> > and your locator/compiler/cache system would just call down to those
> > instead of hardwiring the implementation of compiling and serializing.
>
>of course, this is sensible.  i am not aware immediately of any major
>technical issues to componentizing the internals of myghty, there might be
>some; i doubt they are fundamnetally insurmoutnable.  it would also make
>myghty a more solid system, allow its reloading functionality to be
>useable by other systems that can benefit from it, etc.
>
>but, to do this would be an intense royal pain in the ass and take several
>weeks/months, render new releases of myghty as less stable for awhile,
>etc.  which leads me to believe that if this spec also came along with a
>salaried position +401K benefits for template system developers to spend
>full time re-architecting their systems, id say just great !  otherwise,
>might be a little ambitious for the near-to-medium term.

Heh.  My hope would be that this discussion might lead to a situation where 
a bunch of framework authors could agree to "outsource" much of this 
handling to a single library, which is why I originally wanted to focus on 
template deployment issues.  If we were able to end up with a common way to 
find and load templates (factoring out their "language" to plugins), then 
there would be a need for only a limited number of implementations of that 
mechanism, maybe only one in a future stdlib.  (Granted, specialized needs 
like loading templates from a database would want distinct implementations 
of the "manager" portion, but be able to reuse the "compiler" plugins.)

You may be right about it being too ambitious; I suspect I will need to go 
look at the code and design of at least Myghty and Cheetah in order to 
better understand the issues here.  I must confess I have been thinking 
about template engines strictly in language terms, probably because of my 
own bias towards putting the "manager" part on the "framework" side of the 
line rather than on the "template engine" side of the line.

And I thought the Python web framework world was pretty complex already!  :)