Apologies if you receive this message twice but I didn't want to leave
anybody out.
Now that TurboGears 2 will be built on top of Pylons, it brings an
interesting twist to the templating issue, and in some ways makes it
easier to resolve. Here's what we have so far:
- Buffet 1 is inadequate.
- Smorgasbord has a community-designed API, though I have taken some
liberties with it. Elevind is sending me a patch to finish the entry
points and some other stuff. I'm working on a Pylons patch (a module
that will patch Pylons when you import it). Then Smorgasbord will be
usable in applications and ready for further integration.
- Pylons is "seriously considering" Smorgasbord when it stabilizes.
TG wants "something better than Buffet 1" but hasn't said anything
about Buffet or their requirements for a templating system.
- The Mako/Genshi/Cheetah/Kid/string.Template plugins pass the
regression test. For Kid and Genshi I just did it by the manual, so
I'd like an expert to review the code and suggest how to handle the
options. I couldn't get Breve or Myghty to work so an expert is more
urgent there. (Cliff has promised me a Breve plugin.)
Two major issues have come up: dotted naming and the package name. If
we as as a community can decide on these sooner rather than later,
it'll mean less work by Smorgasbord developers and users to conform to
it later.
DOTTED NAMING
==========
I'd rather drop this completely but I suspect there'll be howls of
protests from TurboGears users as well as Kid/Genshi users that are
accustomed to it. The naming system is what determines how a template
at /myapp/templates/foo/bar.html is identified in the application.
Assuming /myapp/templates is the base path or search path:
Path naming: foo/bar.html
URI naming: /foo/bar.html
Dotted naming: foo.bar
Path naming is what most programmers would expect so it's
Smorgasbord's default. Frameworks can override this with the 'naming'
argument. Pylons and Mako prefer URI naming. Dotted naming is the
default in TurboKid/Genshi/Cheetah and thus in existing TurboGears
applications. But this has problems:
- The suffix is unpredictable and depends on the engine.
- You can't override the suffix.
- Filenames/directories can't have dots in them.
- TurboKid/Genshi/Cheetah require __init__.py files in template
directories but don't actually load the templates in a way that
necessitates this. The 'kid_precompiled' and 'cheetah_precompiled'
options do but I'm probably dropping this in favor of template
caching, which is more template-neutral.
So, do we need dotted naming for TurboGears? Or for Kid & Genshi?
The only impact on Cheetah is that #extends imports precompiled
templates directly, but I'm inclined to let the user worry about where
to put their base templates rather than mandating dotted notation and
__init__.py files for all templates.
PACKAGE NAME
=========
I'd like to call Smorgasbord "Buffet 2" but only with the permission
of Christian and the TurboGears leaders. So that really means
deciding whether this is the direction Buffet 2 wants to go. So,
comments from the Buffet developers?
Smorgasbord is only the package name; the class is Buffet to ease the
transition in case Smorgasbord is renamed later, so that people have
to change only their imports. But it does place a slight burden on
Smorgasbord developers as Elevind has pointed out, to write code which
may have to be revised later.
This also gets into the issue of entry points. I think Buffet 1 uses
"python.templating". Smorgasbord uses "smorgasbord" pending a final
resolution of the package name. Since the plugins are incompatible
with Buffet 1, "python.templating" is out: people may have both Buffet
1 and Smorgasbord applications on the same computer. I hesitate to
use a generic term like "templating" or "buffet" because I think this
should be a community decision: what the entry point should be called
and which API it's linked to.
OPTIONS
=====
The template options and rendering options ('encoding', 'fragment',
etc) are still in my head. Only the options necessary for template
lookup are implemented. I still think standard engine-neutral options
are the way to go for common stuff, but it will require further
research to finish the option handling.
TURBOGEARS VOLUNTEER
================
Is there a TurboGears representative I can work with to hammer out
compatibility issues, somebody who might also be willing to make a TG
patch down the road? Although if TG 2 is running on top of Pylons,
can it simply build on whatever pylons.templating morphs into? But
this comes back to the dotted naming issue also.
Ideally I'd like to see changes in pylons.templating, pylons.config,
and the user's middleware.py. This requires working with Pylons core
developers (Ben, Jimmy, Ian) but it would also help to have a TG
representative in the loop who can make sure TG's needs are met.
Finally, a big "hi" to everybody on the pytemplates list! The list
has been very quiet, and I haven't gotten any feedback on Smorgasbord
except from Cliff and Elevind. Do y'all think Smorgasbord is going in
the right direction and just needs to be completed? Or do you have
disagreements with it or think something else is needed? Or do you
just not care either way (yawn, zzz)?
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
