>> 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.
>> 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 won't help me learn Python any more than learning PHP would.
So going from PHP to Django is pointless.
>> 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.
> 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.
>> 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 we're talking! I will look further into Pylons and Mako.
> 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", but as a hobbiest and not a
coder I myself am "below average". I promise you that _will_improve_,
though.
> 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 see. I will have to spend some time with each to decide, though.
>> 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...
>
The point is that I want to use only _Python_ features, not
Django/Mako/whatever features. 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,
database escaping, etc.
> My 2 cents...
>
A very valuable 2 cents. Thanks.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
--
http://mail.python.org/mailman/listinfo/python-list
