[Web-SIG] Standardized template API

[Ben Bangert]

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