Is there any case where chameleon is more preferred?
Joshua Partogi
I am left undecided whether to use mako or chameleon. From what I have
observed, it seems that chameleon is the default template language in
pyramid (CMIIW). Is there any case where chameleon is more preferred
when using pyramid? I actually like mako but I am afraid there are
some mako functionality that is not supported in pyramid.
Thanks for your help.
--
@jpartogi
Mark Erbaugh
Since Chameleon uses "standard" extensions to HTML, it's more compatible with HTML generating tools.
Mark
Mike Orr
The reason Chameleon seems first is that Pyramid's codebase is a
direct descendant of BFG, which had Chameleon. The Pylons-like parts
were added later, and the tutorial authors happened to be Chameleon
users. Mako was added to Pyramid with the intention that people would
use it, and that they *should* use it if they're more comfortable with
it.
All of Mako is supported in Pyramid. Overall I'd say Mako has more
features than Chameleon and is more flexible. However, one advantage
of Chameleon is that, because it's an XML-based language, the template
is guaranteed to be well-formed if the rendering doesn't raise an
exception. (That doesn't necessarily mean the output will be
well-formed, if your variables contain unbalanced tags and you output
them as literals rather than the default of escaping them.) Also, it
looks Pyramid supports internationalization better with Chameleon
(more documentation, more built-in support). That doesn't mean you
can't do internationalization with Mako, it just means you'd have to
do more of the structural work yourself. (Are there any tutorials on
this?)
One feature that may not be obvious if you're not using the Akhet
scaffold, is that you can define Mako options in the INI file
("mako.directories = line1 line2") or at the beginning of your main
function (``settings["mako.directories"] = [...]``).
I also have used Mako a lot, and have been trying out Chameleon to see
if I might want to use it. My impression is that Chameleon's syntax is
very different, and it takes time to map your Mako idioms to Chameleon
equivalents. So it's only worth doing if you have time to do it
slowly, or if your first Chameleon application requires only simple
templates.
Longer term, Chris has been talking about removing both Chameleon and
Mako from the Pyramid core, making them add-on packages
(pyramid_chameleon and pyramid_mako). They would then be application
dependencies like SQLAlchemy, rather than Pyramid core dependencies.
--
Mike Orr <slugg...@gmail.com>
John Rusnak
Just one person's perspective.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
jerry
with you that XML is by design not suitable for such task.
However, templates are not, and should not be, full-up programs. The
awkward XML programing can actually remind the author to limit the
logic in the template.
Besides, when both the number and complexity of your templates grow,
it'll be appreciated more and more that your final HTML will be well-
formed (and free from XSS attack) so long as each individual template
is validated. This is kind of like unit testing to me.
Last but not the least, XML templates are more designer friendly than
their non-XML counterparts.
That's why I'm still with Genshi while waiting for Chameleon to be
ready for prime time.
Just another perspective.
Jerry
> > Mike Orr <sluggos...@gmail.com>
Chris McDonough
> I tried to write full-up programs in XML/XSLT at work and fully agree
> with you that XML is by design not suitable for such task.
>
> However, templates are not, and should not be, full-up programs. The
> awkward XML programing can actually remind the author to limit the
> logic in the template.
For what it's worth, I've been using ZPT (the syntax that Chameleon
implements) for about 9 years. It's no worse and no better than
anything else; the very act of templating itself blows hard enough that
fighting over what's better is like fighting over the grade of bleach
one should be drinking. None of the problems that I have with
templating HTML could be solved with writing the template in a non-XML
syntax.
> Besides, when both the number and complexity of your templates grow,
> it'll be appreciated more and more that your final HTML will be well-
> formed (and free from XSS attack) so long as each individual template
> is validated. This is kind of like unit testing to me.
>
> Last but not the least, XML templates are more designer friendly than
> their non-XML counterparts.
>
> That's why I'm still with Genshi while waiting for Chameleon to be
> ready for prime time.
You're either going to be waiting a long time, or you should stop
waiting. It's about as good as it's going to get. ;-)
- C
Michael Bayer
On Dec 17, 2011, at 8:28 AM, Joshua Partogi wrote:
There's certainly nothing in Mako that doesn't work in Pyramid. Mako is quite simple and self contained. The caching is the only part that has even some degree of potential for framework integration but this is also very simple.
Now does Pyramid have some features tailored towards Chameleon ? I'm not totally sure but again I bet not really.
Michael Bayer
On Dec 17, 2011, at 9:10 PM, Chris McDonough wrote:
> For what it's worth, I've been using ZPT (the syntax that Chameleon
> implements) for about 9 years. It's no worse and no better than
> anything else; the very act of templating itself blows hard enough that
> fighting over what's better is like fighting over the grade of bleach
> one should be drinking.
Heh, been using ZPT syntax for 9 years and "the act of template blows". I have a blast templating in Mako ! :)
Someday I'll learn traversal. On that day, as I curse and swear how much I despise learning it, I'll start sending you Mako snippets.
Chris McDonough
> On Dec 17, 2011, at 9:10 PM, Chris McDonough wrote:
>
> > For what it's worth, I've been using ZPT (the syntax that Chameleon
> > implements) for about 9 years. It's no worse and no better than
> > anything else; the very act of templating itself blows hard enough that
> > fighting over what's better is like fighting over the grade of bleach
> > one should be drinking.
>
> Heh, been using ZPT syntax for 9 years and "the act of template blows". I have a blast templating in Mako ! :)
Seriously? A blast? If so, my hat is off to you sir.
I hate writing UI with HTML and CSS, period. I don't think any
templating language is going to help that much. I mean unless maybe it
can grant me "special favors". ;-)
- C
Malthe Borch
> I am left undecided whether to use mako or chameleon. From what I have
> observed, it seems that chameleon is the default template language in
> pyramid (CMIIW). Is there any case where chameleon is more preferred
> when using pyramid? I actually like mako but I am afraid there are
> some mako functionality that is not supported in pyramid.
AFAIK, Mako only has rudimentary support for internationalization
(i18n). ZPT (or "page templates") does provide a lot more here.
That said, Mako probably has more features, e.g.:
http://www.makotemplates.org/docs/syntax.html#python-blocks
We don't have that in page templates. You're a bit more constrained.
The good thing in that is that you're likely to be able to quickly
read and understand a page template that someone else wrote, because
there's only a limited complexity there.
As for the fun factor, in the Chameleon implementation there's been an
attempt to make things easier and possibly more "fun", e.g. string
interpolation using ${<expr>}, easy imports of other templates
(relative, absolute or via asset spec), import of Python modules and
module globals, implicit i18n, compatibility with Python 3 etc.
\malthe
Christoph Zwerschke
> Besides, when both the number and complexity of your templates grow,
> it'll be appreciated more and more that your final HTML will be well-
> formed (and free from XSS attack) so long as each individual template
> is validated. This is kind of like unit testing to me.
>
> Last but not the least, XML templates are more designer friendly than
> their non-XML counterparts.
>
> That's why I'm still with Genshi while waiting for Chameleon to be
> ready for prime time.
Though I've mainly used Genshi and its predecessor Kid so far, I doubt
that Chameleon is less mature than Genshi. Anyway, your're right, these
template languages are not meant as a replacement for XSLT. The point is
that as attribute languages they guarantee well-formedness and the
templates themselves are well-formed and valid XHTML, so they can be
processed with design tools and the whole XML tool chain. I like the
fact that you can say <p py:content="therealtext">Lorem ipsum</p> and
preview the template like it was an ordinary HTML file. However, you
need some discipline to write "proper" templates. I see many people
using ${...} substion in Genshi everywhere. If you do this, you loose
the benefits of an attribute language and can just as well use Mako.
Since HTML5 has superseded XHTML, well-formedness is becoming a less
important aspect, and I started to use Jinja2 which has also many nice
features. Jinja2 is also similar to Django templates, so it's more
commonly known and supported by many IDEs (syntax highlighting etc.).
Jinja2 is also available for Pyramid projects via pyramid_jinja2.
-- Christoph
Malthe Borch
> [snip] I see many people using ${...} substion in Genshi
> everywhere. If you do this, you loose the benefits of an attribute language
> and can just as well use Mako.
That's not entirely true. Chameleon knows if its "inside" an attribute
or outside. It also provides you the static attribute default (as the
variable "default").
> Since HTML5 has superseded XHTML, well-formedness is becoming a less
> important aspect, and I started to use Jinja2 which has also many nice
> features. Jinja2 is also similar to Django templates, so it's more commonly
> known and supported by many IDEs (syntax highlighting etc.). Jinja2 is also
> available for Pyramid projects via pyramid_jinja2.
How is HTML5 changing the XML-ness of HTML?
\malthe
Christoph Zwerschke
> That's not entirely true. Chameleon knows if its "inside" an attribute
> or outside. It also provides you the static attribute default (as the
> variable "default").
I was not talking about using ${...} in attributes, but virtually
everywhere, i.e. instead of using tal:content, tal:replace etc.
> How is HTML5 changing the XML-ness of HTML?
The point is that HTML5 doesn't require well-formedness as XHTML did. Of
course creating well-formed output is still the goal, but it has become
a less crucial issue as it was in XHTML.
-- Christoph
Chris Withers
Meld or Twiddler ftw!
</troll>
In order of rusty-spoon-kneecap-removing preference:
- ZPT, any sane implementation thereof
- Django/Jinja/etc and friends
- Mako
But, as mcdonc said, it's marginal, they all suck in different and
special ways. My gripe with Mako is that it's too easy to generate
invalid html, my gripe with ZPT is that it's *hard* to generate valid
CSS/JS. Of course, Tiddler is awesome, shame it's unmaintained and
performance sucks rocks through straws - so yeah, I would choose an
amusing bleach grade, but there aren't any:
http://www.google.co.uk/search?q=amusing+bleach+brands
Anyway, back to trying to get mysqldb to compile on yet another
operating system... *sigh*
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
Vlad K.
It's not the question of "well-formedness" but the difference between
HTML and XHTML. XHTML must comply to XML formatting rules (for example,
self-closing tags) because it is essentially XML with HTML namespace (as
default), HTML has no such requirement, but is "backward" compatible
with XHTML in that it allows self-closing tags.
There is also difference how special namespaces are handled between
both, that's why there are currently issues (if you observe it from the
standpoint of a purist validator) with OpenGraph namespaces and
HTML+RDF, etc...
HTML5 also allows custom tag attributes which is awesome and you don't
need complex XML namespacing schemes for that.
.oO V Oo.
Malthe Borch
> But, as mcdonc said, it's marginal, they all suck in different and special
> ways. My gripe with Mako is that it's too easy to generate invalid html, my
> gripe with ZPT is that it's *hard* to generate valid CSS/JS.
Bit of a cheap gripe I feel, seemingly as ZPT wasn't designed to
generate non-structured documents.
With Chameleon, you can actually write text templates (i.e. non-XML)
and do simple expression substitution using ${...} but that's about
it. What else do you need?
\malthe
Joshua Partogi
being and let's see I can go forth without banging my head against the
wall. Everyone else may continue the discussion.
Thanks all.
On Dec 17, 7:14 pm, Mike Orr <sluggos...@gmail.com> wrote:
> On Sat, Dec 17, 2011 at 5:28 AM, Joshua Partogi
>
> Mike Orr <sluggos...@gmail.com>