On Feb 4, 2006, at 10:55 AM, Phillip J. Eby wrote:
> But that's the case that threw this whole thing off track to begin
> with, because you can only pass in a find_template if *you're the
> template manager*. In the interface we're currently discussing,
> finding templates is internal to the engine, so that bit doesn't
> come up.
Yes, I noticed this, because the next step it led to was having a
load_template, then we're down the slippery slope to standardizing
internals.
> That is, if you have a Myghty "get(template_id)", then clearly it's
> Myghty that does the finding, so how would you *give* Myghty a
> finder? You've already said that Myghty has to use its own finder,
> didn't you?
Agreed, it does. find_template should be optional, because its of no
use to Myghty. Myghty needs merely the template name and the template
root. Of course, merely having a find_template does imply that if a
template include or uses another template, the template language
itself must be aware it should be using find_template....
So yes, find_template quickly leads to standardizing internals of the
template language, I agree that it should either not be present, or
be optional.
> If you mean the __init__() signature, I'd agree, but IIUC the
> extra_vars_func isn't needed since the caller's responsible for
> adding those to the WSGI environ at call time. Unless I'm
> misunderstanding its purpose?
No, I think you got it, I'm referring to the __init__ for each
individual template engine.
> So, the framework can expose a TGManager that offers the standard
> get_template() and follows the framework's policy for determining
> what engine to invoke; the above is just implementing what I
> believe is Turbogears' current policy for such.
Makes sense.
> So, initialization and policy of one of these animals is framework-
> specific as I understand it. But the framework should expose the
> manager, and it can be recommended that it be included as an
> environ item, so that an application could use something like
> 'environ["wsgi.template_engine"].get_template("some_id")' to obtain
> a template. (Of course, that only matters for frameworks that are
> exposing WSGI to application code, or if you want to give a
> template access to the template engine, even though it should
> already have a direct line to the engine internally.)
I think that'll be fine, we probably need an updated bit of sample
code to look at now.
> Unfortunately, it doesn't. Didn't you just point out that Myghty
> isn't going to actually *use* that find_template callable? If not,
> then what good does it do to pass it in?
I think the main reason Ian suggested it was because he wanted to
implement his own lookup scheme to find templates. As I mentioned
above, this begins to take us to the internals.... so I'm inclined to
agree that its not going to help here.
> I think the TG API is pretty close to what we're going to end up
> with, except that rendering takes place via WSGI. I don't see a
> problem with treating the other existing TG methods (render and
> transform) as optional extension APIs; I just don't want those to
> be "the standard" for how you plug templates into a framework,
> since it makes object publisher and active page systems into second-
> class citizens grubbing for scraps of text, so to speak. :)
Ok, sounds great. Anyone up for throwing some pseudo-code?
Cheers,
Ben
_______________________________________________
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
