[Web-SIG] Standardized template API
mike_mp at zzzcomputing.com
Sat Feb 4 00:12:45 CET 2006
I would add that the locating/compiling system, like Ben is mentioning,
would also need to be accessible from within the template engine; i.e.
these components need to be linkable together in recursive chains. that
is because most template engines have the ability to call sub-templates,
and this is a core functionality of myghty...very nested and recursive,
also keeps an internal stack frame going to track the whole thing.
Michael Bayer wrote:
> Phillip J. Eby wrote:
>> What I'd suggest is that this is actually an opportunity for Myghty to
>> its lookup and caching on one side of the interface, and an actual
>> 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
>> 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
>> locating, compiling, and caching templates, then it should live on the
>> framework side of the "engine" interface. An embedding engine offers
>> "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.
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
More information about the Web-SIG