> Ideally, for a significant class of frameworks it would be nice if they > could all be interfaced in the same way. I.e., you pass in a namespace, > and maybe a "template space" as well, when templates look up up other > templates (as with ZPT macros, standard headers/footers in other other > languages, etc). There's small but subtle differences between > templates, but maybe those could be papered over.
theres been a lot going on with Myghty with regards to the Resolver object, which is the object responsible for converting paths into sources of template component code, which usually come from template files stored in one or more root directories, but also can be defined within Python modules as well. of particular use is that you can pass in whatever kind of Resolver you want if you dont like the way it resolves. Now, since some people didnt like the way it resolved, *and* didnt want to write their own resolver, I will be adding in to the default resolver a full blown ruleset engine where you can drop in as many resolution rules as you like into your own custom rule lists. anyway, it would be straightforward to add new resolution rules that return sources to template objects from other platforms. the tricky part is that two templates from library A and library B both probably need to present a slightly adapted form of themselves to each other, like a multi-contextual object of some kind where each one can locate its familiar namespace bits. _______________________________________________ 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
