The Artima Developer Community
Sponsored Link

Weblogs Forum
Django vs. Cheetah: 1-0

86 replies on 6 pages. Most recent reply: Jan 27, 2008 10:34 PM by Johnny Stovall

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 86 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]
Eugene Lazutkin

Posts: 15
Nickname: elazutkin
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 11:04 AM
Reply to this message Reply
Advertisement
> > Anyone know if it's possible to use htmltext with
> Django?
>
> You don't have to run things through the Django templates,
> so that shouldn't be very hard.
>
> (I still recommend Django's templating for boilerplate and
> overall site design, but generating the body (or other
> fragments) with a tool that's better suited for your
> application works perfectly well.)


Hear hear! People are forgetting that it is impossible for a single template engine to cater for all tastes. You should use tools appropriate for your task. For example, Django documents are generated using restructured text processor, which is piped in to the regular Django template engine. Another example is RSS generation, which uses Python XML DOM tools to create a valid feed.

mike bayer

Posts: 22
Nickname: zzzeek
Registered: Jan, 2005

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 11:36 AM
Reply to this message Reply
> And why would being a port of something in Perl be a good
> thing? Most Python modules that were ported from another
> language's popular API (e.g. threading.py, unittest.py,
> and the whole XML DOM thing) suffer from some amount of
> braindamage due to not being sufficiently Pythonic.

Well, in coming to Python I definitely had a very good look around at everything available. By far, the one template tool that provided the functionality and extensibility I wanted was Spyce (http://spyce.sf.net). However, Spyce was a little inconsistent in its usage, the source code was definitely not industrial strength, its owner at the time was MIA, and the community didnt seem to be interested in my ideas. Spyce has since gotten a new owner, moved to 2.0, and actually integrated the thing that I wanted, which was template inheritance.

HTML::Mason on the other hand had already proved itself with me as the best dynamic-language based template system out there, and it works quite well for Amazon.com and del.icio.us. As it turns out, its constructs were very compatible with those of Python.

I have observed two things with Myghty: that nearly everyone is immediately turned off by it when they first see it, and that everyone who ultimately uses it (and doesnt have a problem writing their own application around it) can immediately see that its feel, its construction, and its componentized layout is by far the best thing available for Python. Nobody has come to me and said, "this is not pythonic enough, it feels like crappy perl code". Trust me, nobody wants to get away from crappy perl code more than I do. You'd have to dig into it just a little to really see what its about. Whereas Django definitely has shallow newbie appeal, its design concepts will definitely become a letdown on a large project; while you might go and develop your project's first version with it, I am sure that you will eventually be back looking for something else within a few months if not sooner.


> Apart from the admitted prejudice, I looked at the example
> in the next post, and both the templating language and the
> API look horrible to me. What's the advantage of using
> ARGS['name'] instead of $name? Why do they call
> files/streams buffers? Why is the output stream declared
> when the interpreter is created? Why do I need an
> interpreter object (apart from remembering the output
> stream, which seems too-early binding anyway)? I could go
> on; every aspect of it either looks Perlish or smells like
> a dinosaur.

Well a comparison using the "how to construct a template from a string and run it" is a totally irrelevant test. If I want to do that, I usually use '"hello %s" % name'. In reality, a decent web application has at most one line of code within the entire thing that is dealing with the semantics of invoking a template, and it will have hundreds if not thousands of lines of actual template code. *That* is the part you should be judging a template language on. Myghty also usually involves setting up a mod_python config or similar so the actual invocation of the template is not explicitly stated at all.

As for <%args>, Myghty's components act like functions; just as a function must declare the argument list of the variables it wants to have in its local namespace, so should a component. It is a very small-fry design to automatically import every single name in the original request namespace into the template namespace; in a bigger situation with hundreds of interrelated components, having an explicit signature is the way to go. ARGS is then just a dictionary that allows access to the full namespace.

> I'm not sure that more templating power is really needed;
> and all the contenders are extensible so by definition you
> can have all the power you need.

thats like middle-management mumbo jumbo speak. How do you define "extensible" ? is it extensible in the way you want it to be ? What performance and construction overhead is incurred by extensions ? how well do your extensions integrate with the existing template environment ? I dont see how you can think Django is extensible when its very design philosophy states that it is opposed to any kind of interoperability with the outside world.

The Myghty approach definitely is designed to appeal to those who have worked in the web building trenches for a long time....as it seems most of the Python community is interested in building blogs and other small-scale applications, its not surprising that Myghty remains largely undiscovered. My goal is to bring Python into the forefront of web application construction, as a replacement for Java/JSP, PHP, etc. I think most of the stuff out there, while appealing to start with, when put into rough real-world situations will prove to be a letdown. As one who has been let down by dozens of various tools and approaches for over a decade, I am confident that Myghty has the best "no letdowns" design in the whole Python community.

Adrian Holovaty

Posts: 5
Nickname: holovaty
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 11:50 AM
Reply to this message Reply
mike bayer wrote:
> I dont see how you can think Django is
> extensible when its very design philosophy states that it
> is opposed to any kind of interoperability with the
> outside world.

Hey Mike,

You can write custom template tags and filters in Django templates, which do anything (in Python) that you want them to do. Check out the docs here:

http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system

If you can think of something that doesn't allow you to do, I'd love to hear it. :)

Adrian

Shannon -jj Behrens

Posts: 12
Nickname: jjinux
Registered: Aug, 2005

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 12:06 PM
Reply to this message Reply
To be fair, I can guarantee that both Cheetah and Myghty are "industrial strength". I'm sure many of the others are as well. At my company we have over 100,000 lines of Cheetah. Tavis Rudd's applications are similar.

What I'm trying to say is, there *is* more than one good templating solution available in Python. It *does* come down to taste and specific needs.

mike bayer

Posts: 22
Nickname: zzzeek
Registered: Jan, 2005

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 12:10 PM
Reply to this message Reply
> Hey Mike,
>
> You can write custom template tags and filters in Django
> templates, which do anything (in Python) that you want
> them to do. Check out the docs here:
>
> http://www.djangoproject.com/documentation/templates_python
> /#extending-the-template-system
>
> If you can think of something that doesn't allow you to
> do, I'd love to hear it. :)

Id like to run a Django template in Python Paste and have it talk to SQLObject.

- mike

Adrian Holovaty

Posts: 5
Nickname: holovaty
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 12:34 PM
Reply to this message Reply
mike bayer wrote:
> Id like to run a Django template in Python Paste and have
> it talk to SQLObject.

Ah, I thought we were talking about extending template-system functionality.

But, since you asked, all you'd have to do is this, somewhere in your app:

"""
from django.core import template
from module_that_has_sqlobject_classes import Person

t = template.Template('blah blah {{ obj.firstName }}')
c = template.Context({'obj': Person.get(1)})
print t.render(c)
"""

(This assumes the Person class found in the SQLObject docs here: http://sqlobject.org/SQLObject.html .)

Note that at the moment Django needs an environment variable DJANGO_SETTINGS_MODULE, as Guido mentioned, but that dependency for the template system will soon go away -- as I mentioned in a previous comment in this forum.

Have you used Django? If you did, I think you'd find its layers are quite decoupled. We should (and will) make available its parts as separate components, but it's already quite possible to use the various bits on their own.

Adrian

Tavis Rudd

Posts: 13
Nickname: tavis
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 12:46 PM
Reply to this message Reply
Mike, I think you're overstating Myghty's strengths vs. other template systems without fully understanding the others. Django, for example, has proven itself on high traffic sites: washingtonpost.com

adrian wrote:
> Hey Mike,
>
> You can write custom template tags and filters in Django
> templates, which do anything (in Python) that you want
> them to do. Check out the docs here:
>
> http://www.djangoproject.com/documentation/templates_python
> /#extending-the-template-system
>
> If you can think of something that doesn't allow you to
> do, I'd love to hear it. :)
>
> Adrian

The same is true of Cheetah. You can interact with any Python object from within a template. You can subclass any Python class. You can customize the parsing and behaviour of any standard #directive. You can add custom #directives, either using the default parser's methods or providing your own. You can write compile-time macro directives (just like Lisp macros) inside your templates and call them to manipulate Cheetah source on the fly at compile time. These macros can also be written in Python and reused among templates. You can also call *any* other template system that provides a Python interface, directly from within a Cheetah template:

"""
#from nevow import flat, tags
#set aDocument = tags.html[
tags.head[
tags.title['Hello, world!']
],
tags.body[
tags.h1[ 'This is a complete XHTML document modeled in Stan.' ],
tags.p[ 'This text is inside a paragraph tag.' ],
tags.div(style="color: blue; width: 200px; background-color: yellow;")[
'And this is a coloured div.'
]
]
]

Here is the output of a stan template used within Cheetah:
$flat.flatten(aDocument)
blah blah
"""

You can also create simple macros that facilitate the embedding of other template syntaxes inline inside Cheetah source like this:
"""
#stan
h1['A Stan h1 tag.' ],
p['This text is inside a paragraph tag.'],
div(style="color: blue; width: 200px; background-color: yellow;")[
'a coloured div with a $cheetahPlaceholder in it.'
]
#end stan
"""

mike bayer

Posts: 22
Nickname: zzzeek
Registered: Jan, 2005

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:02 PM
Reply to this message Reply
> The same is true of Cheetah. You can interact with any
> Python object from within a template. You can subclass any
> Python class. You can customize the parsing and behaviour
> of any standard #directive. You can add custom
> #directives, either using the default parser's methods or
> providing your own. You can write compile-time macro
> directives (just like Lisp macros) inside your templates
> and call them to manipulate Cheetah source on the fly at
> compile time. These macros can also be written in Python
> and reused among templates. You can also call *any* other
> template system that provides a Python interface, directly
> from within a Cheetah template:

You should note that I have reserved comment on Cheetah since I think it is a pretty good template system. Django templates, OTOH, look like PHP to me (huge lists of functions). My post was mostly responding to the notion that Myghty is not worthy a. because its based on a Perl idea b. because the interface to run a small string-based template is a not a beautiful work of elegance and c. because it wants you to pre-declare arguments.

I would most like to see Guido compare Cheetah and Myghty templates (and Django, and Stan, and Kid I think its unfortunate hes 100% dismissive of the XML idea as well), try building some small sites with each one, insure that he can get them to interface with WSGI adequately, and then pick one. I think Cheetah is probably more his style anyway since it appeals to Python purists more. I just would prefer that Guido, or anyone else, doesnt look at one line of Myghty template code and then dismiss the whole thing for some shallow reason. Seems like thats a theme in all these web-shootout kinds of threads.

Andrew Kuchling

Posts: 4
Nickname: amk
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:20 PM
Reply to this message Reply
> You don't have to run things through the Django templates,
> so that shouldn't be very hard.

No, that's not what I mean. I don't care about using PTL with Django. I care about giving Django's templating the property that data is always escaped properly, but never double-escaped.

Tavis Rudd

Posts: 13
Nickname: tavis
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:23 PM
Reply to this message Reply
mike:
> I just
> would prefer that Guido, or anyone else, doesnt look at
> one line of Myghty template code and then dismiss the
> whole thing for some shallow reason. Seems like thats a
> theme in all these web-shootout kinds of threads.

That's a very good point. Until you have *real* experience with templating in general and with a particular template system it is damn near impossible to pass judgement. I've been working with various template systems for almost a decade now (including mason) and my ideas of what I need and what I like have changed significantly.

Phillip J. Eby

Posts: 28
Nickname: pje
Registered: Dec, 2004

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:31 PM
Reply to this message Reply
Currently, the only way to install setuptools for Python 2.5 is to check out setuptools from the Python SVN sandbox and run "setup.py install". Once you've done that, you should be able to use any packages out there (such as Django) that use setuptools, easy_install, ez_setup, etc.

Chris Stromberger

Posts: 3
Nickname: cstrombe
Registered: Jun, 2004

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:47 PM
Reply to this message Reply
> I hate stuff like:
>
> {%if name%}
> <h1>Hello {{name}}</h1>
> {%else%}
> <h1>Hello There</h1>
> {%endif%}
>
> Making good looking HTML is hard enough without mixing it
> with a programming language.

I agree. Looks like PHP, no? No gracias.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:50 PM
Reply to this message Reply
> I care about giving Django's templating the
> property that data is always escaped properly, but never
> double-escaped.

Perhaps this is another area where different template libraries could cooperate. If the type (class) of already-escaped data was different from the type of unescaped (regular) strings, we could have an escape() function that returned its argument unchanged if it was of the special type, and otherwise escaped it, returning an instance of that type. There should also be a way to create an instance of that type directly from a string.

Of course this is pretty much exactly the Quixote approach, IIRC, except it shouldn't require hacking the Python interpreter or (equivalently) preprocessing Python source, and the same type (or interface, at least) should be supported by all templating libraries. Maybe someone could write up a PEP? I think it ought to be part of the Python standard library (eventually).

Tavis Rudd

Posts: 13
Nickname: tavis
Registered: Jan, 2006

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 1:54 PM
Reply to this message Reply
Mike Orr has been working on something that sounds like it would allow libs to cooperate on escaping. +1 to standardizing it.

> Perhaps this is another area where different template
> libraries could cooperate. If the type (class) of
> already-escaped data was different from the type of
> unescaped (regular) strings, we could have an escape()
> function that returned its argument unchanged if it was of
> the special type, and otherwise escaped it, returning an
> instance of that type. There should also be a way to
> create an instance of that type directly from a string.
>
> Of course this is pretty much exactly the Quixote
> approach, IIRC, except it shouldn't require hacking the
> Python interpreter or (equivalently) preprocessing Python
> source, and the same type (or interface, at least) should
> be supported by all templating libraries. Maybe someone
> could write up a PEP? I think it ought to be part of the
> Python standard library (eventually).

Fredrik Lundh

Posts: 16
Nickname: effbot
Registered: Mar, 2005

Re: Django vs. Cheetah: 1-0 Posted: Jan 31, 2006 2:00 PM
Reply to this message Reply
> I care about giving Django's templating the
> property that data is always escaped properly,
> but never double-escaped.

One way to do this in Django is to wrap return values from a model in a "safe string" wrapper, and use a custom filter function to render it as HTML CDATA in the template. Something like (untested)

# wrapper
class SafeText:
def __init__(self, text):
self.text = text
self.html = None
def __str__(self):
return "(use htmltext to render this object)"

# filter
def htmltext(text):
if not isinstance(text, SafeText):
return text
if text.html is None:
text.html = escape(text.text)
text.text = None
return text.html

register.filter("htmltext", htmltext)


could work.

If you attempt to display a wrapped string without feeding it through the htmltext filter, all you get is the text "(use htmltext to render this object)"...

(this approach might be a bit impractical if you have tons of variables, though)

Flat View: This topic has 86 replies on 6 pages [ « | 1  2  3  4  5  6 | » ]
Topic: Django vs. Cheetah: 1-0 Previous Topic   Next Topic Topic: ScalaTest 0.9 Released

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use