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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
