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 >> 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/mike_mp%40zzzcomputing.com > _______________________________________________ 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