Dotan Cohen a écrit :
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.
It is clear and obvious. But it has the "template engine" duplicating
a function that Python has built in. My goal is to learn reusable
Python (reusable for non-web projects). My goal is not to find the
quickest way to a website.
Please correct me if I'm wrong, but you did learn HTML, CSS and SQL,
didn't you ? How do any of these languages relates to Python ?-)
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 !-)
It is not a great challenge, but it is redundant. Learning Django
language
<pedantic>
Django's templating language, actually
</pedantic>
won't help me learn Python any more than learning PHP would.
So going from PHP to Django is pointless.
Please get out of the "server page" mindset. Templates are just that :
templates. Period. You don't use templates to write your *applicative* code.
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.
I meant reusable knowledge, not reusable code.
There's very few "reusable knowledge" to be gained from templating code
anyway- even if using a "python-based" template system like Mako. Unless
you think doing a loop or a conditional are things you need to learn ?-)
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 think that the time that I invest codng in Python as opposed to
Django Template Language is time well spent.
Then write your own templating system - and your own framework FWIW !-)
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.
Now we're talking! I will look further into Pylons and Mako.
Beware that the above comments about how less there's to learn from the
templates code still apply - basically, the "programming" part of a
template is restricted to simple branching, iterations, and variable
substitution.
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.
I don't expect to ever have a "team",
Possibly not. But as strange as it migh be, there are other peoples that
do, and most of these frameworks are written by professional web
programmers.
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 see. I will have to spend some time with each to decide, though.
That's usually the best thing to do - take a couple days doing the
tutorials, and choose the one that fits your brain.
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...
The point is that I want to use only _Python_ features, not
Django/Mako/whatever features.
If so, you shouldn't use *any* third-part libs, and possibly not even
the stdlib.
More seriously : reinventing the wheel - unless for educational purposes
- is not really pythonic. If what you want is to learn, write your own
framework, template system, form handling etc... You'll very certainly
find out that they suck big time compared to existing projects, but
you'll learn _at least_ one thing: that writing a sensible non-trivial
framework or lib is *hard*.
Once again, been here, done that...
However I am aware that some things I
should not touch for security reasons. That is why I want a framework:
to provide the security aspects of things like converting UTF-8,
from what and to what ?-)
string / unicode encoding and decoding is a builtin Python feature.
database escaping,
Already provided by any DB-API compliant connector, at least if
correctly used.
Now there's *much* more in security (specially when doing web
programming) than this...
--
http://mail.python.org/mailman/listinfo/python-list
