Hi Pat,
Let me start with a brief bit about where that template plugin
document came from and what happened since.
TurboGears originally supported just Kid for templating. For a couple
of reasons, I needed to add support for different template engines.
Around the same time that I was going to do that, Christian
Wyglendowski released Buffet, which supported multiple template
engines (but not plugins) and picked up TG's "return dict" style of
working.
So, we got together and implemented the inteface more-or-less in line
with what TG was doing and needed to do. When I wrote that document, I
wasn't looking at it completely with an "open on both sides" mindset.
It was more of a "get something up there so that people can fit
engines for TG". And people did manage to plug a good collection of
engines in.
Then came the massive threads of discussion on web-sig, and a little
discussion on a new mailing list just for python template engine
interfaces.
So, the current state of the interface is that it's still fairly TG
specific. We'd all like there to be some changes, but no one has
stepped forward to pick up the task.
On 6/13/06, Patrick Maupin <[EMAIL PROTECTED]> wrote:
>
> I am working on yet another templating system (yeah, I know, but the
> ratio of web frameworks to templating systems has just gotten too
> high). Its primary focus is not really the web, although it would be
> nice to make it "just work" on the web, as well.
I'd be curious to hear about "what's new" in your template system...
> steeped in TurboGears lore and practices. If the answers are't too
> self-evident to TurboGearHeads, perhaps the doc page could be
> updated...)
The interface and the doc page needs updating :)
> 1. In __init__(), it specifies that "the options should be prefixed
> with the engine's scheme name...". Is this prefixing done with a
> colon, or a period, or any separator at all? (I thought I saw both
> dots and colons used to separate prefixes for various different
> purposes in the TurboGears docs.)
In line with CherryPy's config style, I use dots. It actually doesn't
really matter. The main point was "don't clobber other folks
configuration".
> 2. In render(), the "template" parameter is not described. Is this
> the same as the load_template() "templatename" parameter, or is it an
> actual template, as returned by load_template()? (The documentation
> would appear to indicate it is not the latter, but then why isn't it
> clearly named "templatename" like the load_template() parameter?) The
> default is "None" -- is "None" ever passed in, and if so what should
> the function do with it -- use the result of the most recent call to
> load_template()?
It is the name of the template.
> 3. I guess some of my confusion (about what happens in question 2)
> revolves around the lack of discussion about the use of the YourPlugin
> class by the system. Is it instantiated once? Once per thread? Once
> per template used?
In TG, at least, it's instantiated once.
> 4. I assume that render() should return a string. This is certainly
> implied by the docstring comment, but is not spelled out in black and
> white.
Yes, return a string.
> 5. Template context data is defined in two ways -- the info
> parameter passed to render(), and by calling the optional
> extra_vars_func().
> a. Is the template engine allowed to modify the dictionary
> returned from extra_vars_func?
> b. Is the template engine allowed to modify the info parameter
> dictionary? (e.g. by adding __builtins__)
> c. If there is a name collision between these two
> dictionaries, which one takes precedence?
> d. Although the fact that extra_vars_func() should be called
> on every render() is documented at __init__(), this should probably be
> reinforced at the documentation for render().
I don't think that *this* plugin interface will ever be specified to
that degree. If and when we actually start implementing the next
increment of the interface, then we can definitely get into that
detail.
TurboKid explicitly copies (shallow copy) the data and info takes
precedence over extra vars:
data = dict()
if self.get_extra_vars:
data.update(self.get_extra_vars())
data.update(info)
> 6. How is the result from the transform() method used? (e.g.
> directly by TurboGears, or by piping it back into the templating
> package?) If it's the latter, does the transform() method have to
> return an elementtree representation, or could it return some other
> representation which is meaningful to the templating package and
> efficient to generate and use?
This is the most TG-specific thing in there. Kid is efficient at
generating and consuming Elements, so this exists to avoid round-trips
between text and Elements for TurboGears widgets.
I would recommend just ignoring this one.
> Additional questions:
>
> 7. In the setup.py entry point section it shows "schemename =
> yourpackage.yourmodule:YourPluginClass". I would assume that it should
> really be "yourschemename" as well, but I hate making those kinds of
> assumptions.
Yes. "yourschemename"
> 8. There is scant discussion on caching templates. Should they always
> be cached? How are stale templates flushed out of the cache? I was
> under the impression from something I read earlier that changing a
> template would cause TurboGears to reload, but I don't see anything in
> the interface for this.
This is definitely up to the plugin. The discussion on the python
template engine list has been centered around more flexible discovery
of templates, which is important. Caching fits much more into that.
For the current interface, though, it makes sense for the engine to
handle caching/reloading because it's actually the only thing that
understands how to do that.
Kevin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
