[Web-SIG] Standardized template API

Michael Bayer mike_mp at zzzcomputing.com
Sat Feb 4 00:08:39 CET 2006

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.

More information about the Web-SIG mailing list