Dotan Cohen a écrit :
Perhaps this might better answer your questions:
http://docs.djangoproject.com/en/dev/topics/templates/#id1
Actually, that example just proves my point!
Which one ?
Look at this "templating code":
{% for entry in blog_entries %}
<h2>{{ entry.title }}</h2>
<p>{{ entry.body }}</p>
{% endfor %}
What's the problem ? Simple, clear and obvious.
Why would I want to learn that when Python already has a real for
loop ?
If you know even 101 Python, understanding the above code shouldn't be
such a great challenge !-)
I know HTML, and I have a goal of learning Python for it's
reusability (desktop apps, for instance).
Using templates instead of harcoding HTML in the applicative code
actually plays a big part when it comes to reusability. Telling Django's
template loader where to look for templates is just a matter of
configuration, so using templates you can segment your whole project in
small, possibly reusable apps - then in another project where you need
the same features but with a totally different presentation, it's just a
matter of writing project-specific templates. Quite a few django apps
work that way, and they really save you a LOT of time. This wouldn't be
possible using your beloved antipattern...
I don't want to learn some
"templating language" that duplicates what Python already has built
in!
Then use Mako - it uses plain Python to manage the presentation logic.
And if you go for Mako, then you might as well switch to Pylons. Great
framework too (better than Django on some parts FWIW), but you'll
probably need much more time to be fully productive with it (power and
flexibility come with a price...).
Now wrt/ "why having a distinct templating language", there are pros and
cons. On the pros side, having a language that is clearly restricted to
presentation logic prevents you (and anyone else working on the project
- and sometimes you have to deal with well-below-average guys in your
team) to put anything else than presentation logic in the templates.
Bless me for I have sinned - sometimes, when you're tired and under
pressure to deliver in time, it's tempting to add a Q&D hack in the
presentation part instead of DoingTheRightThing(tm). This can save you
some "precious" minutes now. The problem is that usually your boss won't
give you the resources to clean up this mess once you delivered, and
next time you have to work on this project - fix or evolution - you have
to deal with this hack. Then with another, yet another, until your code
is nothing more than an unmaintainable heap of junk. Been here, done
that, bought the T-shirt :(
Also remember that most of the time, a web app is a team effort, and
even if *you* don't fail to temptation, others may do so. And finally,
the team usually involve "HTML coders" - who, despite what the name
seems to imply, are usually skilled enough to handle the presentation
logic by themselves, so you the application programmer can concentrate
on applicative code. From experience, they usually prefer a simple
straightforward - even if somehow restricted - templating language.
Now, as far as I'm concerned, having Mako instead of Django's templates
wouldn't bother me at all. But Django has it's own template system,
which from experience get the job done (believe me, there are way worse
alternatives), and the overall qualities and features of the whole
framework are IMHO enough to justify learning it's templating language.
I think that I will use the HTTP-abstraction features of Django, but
disregard the templates. My code might be uglier, but the knowledge
will be transferable to other projects. My ultimate goal is not to
make the latest greatest website. My ultimate goal is to port my
perfectly functional website to a language that will benefit me by
knowing it.
Given the restricted and rather unintersting nature of pure presentation
logic, you won't learn much from this part of the project anyway. You'd
probably learn way more using Django's templates and learning how to
write your own template tags. Or if you prefer Mako / Pylons, learning
to make proper use of Mako's advanced features. But one thing is clear -
if you persist on applying your favorite antipattern, you'll just waste
more of your time. Your choice, as usual...
My 2 cents...
--
http://mail.python.org/mailman/listinfo/python-list
