>py:def is excellent, and I love the way you can pass arguments to it,
>and it simply works! This is one of the worse parts about metal, I
>agree
Yes, and it's easy to debug normal function calls! It's well worth
turning on the environment variable that leaves the generated python
files on disk (KID_OUTPUT_PY) (make sure you have the latest from svn
with the patch to make that work in normal operation). Then you can look
at the code at the line numbers it prints in the stack trace to see
what's going on.
I think with a few changes, kid templates could be even easier to debug.
First of all, it needs to be dead easy to identify xml syntax errors, so
a nice error message showing the file name and context would be helpful.
I'd also like to have it give better error messages and stack traces, to
help figure out which templates are on the stack. Zope has a way of
defining magically named local variables with useful traceback
information that's displayed in stack dumps, which I miss (but I can't
remember the variable name off the top of my head), but it should be
easy to add that debugging mechanism to Kid. Then it could insert the
names and parameters of the templates being executed into the stack
traces, so they made more sense.
>Still, I think the macro/slot concept is really good and it has no
>equivalent in Kid (yet). Again, if I wanted Zope or Plone with all its
>issues, I'd use Zope or Plone :)
I agree! Kid's flexible enough that you can write a simple slot filling
system in Python, as utilities in the base template class from which
your templates inherit. It's possible to layer a higher level template
system on top of kid in this way, without compromising the simplicity of
the core system.
>I never said I wanted acquisition (though Plone uses it for its
>skinning system). Zope3 for example has no (implicit) acquisition but
>it has a similar layer/skin system.
I've never heard of anyone who actually wanted acquisition! ;-) I'm glad
it's gone from Zope 3.
>Again, I don't want TG or Kid to become Zope, Plone or ZPT. What I do
miss >is:
>Defining views independend of code. Currently you're supposed to
>return html from your methods or define which template to use through
>expose(). This is fixed and there's no way to override the defined
>template (Right? Or am I missing something?)
Good news: you can return a dict with a key tg_template that names the
template you want to use, which overrides the template declared in the
@turbogears.expose wrapper! That's handy for returning error messages
and redirecting to other templates.
>kid is indeed really pythonic, and I think it's alot clearer than ZPT
>/ Tal. However, it has its limitations, py:def just can't handle my
>usecases, which include including pieces of templates "from elsewhere"
>and have parts of that template filled in, i.e. [...]
>passing title/intro/body as arguments to a pythonmethod would really be
>messy.
It would be nice to be able to pass the content of the calling element
to functions defined by py:def, so you can do lisp-macro-like stuff like
defining your own control structures. And also a shorthand for calling
<dummy py:replace="foobar(arg=1, content=item)">content args</dummy>
that looks like <foobar arg="1">content args</foobar>, which explicitly
calls the function at macro expansion time (instead of being applied in
a less efficient post-processing step like match templates), and passes
the calling element to the function as an additional argument, so it can
pull content and attributes out of the calling element, transform it,
and return whatever it wants.
A common pattern that Kid could support better is data binding:
transforming one XML tree into another, recursing down a tree of XML,
merging it with other data, and producing a complex transformation of
XML data to another XML format or HTML. OpenLaszlo has an excellent XML
data binding system that uses XPath and constraints, which I really
enjoy.
>Perhaps I Just want too much flexibility, but this is what I currently
>need for my project, partially because I want to generate a default
>set of widgets,forms,etc and have people customize only those parts
>that they want to be different.
I think Kid is an excellent and sound design, which can be extended to
support what you need by inheriting from optional utility templates,
without spoiling its wonderful simplicity.
-Don
