Am 22.08.2006 um 18:22 schrieb James Bennett:
> Some things that occur to me on other points:
>
> * Admin, auth and comments using Django's own ORM, template system,
> etc.: well... what are we supposed to use? They're Django
> applications, and they leverage as much or as little of Django as they
> need to accomplish their goals. Also, it is possible to use another
> ORM with Django and still use the admin app.
You're taking the original statement out of context. The context was
the often-heard argument that Django lets you replace any subsystem
if you prefer using a different library. What's less often-heard is
that if you do so, you are giving up a lot of the niceties that
Django provides (such as the admin if you use a different ORM)
> * Database connection pooling: not sure what's up with this. The
> multi-db branch looks fairly stable, but that's not what comes to mind
> when I think "database connection pooling", and what comes to mind
> when I think "database connection pooling" isn't something I think
> belongs in Django.
Karl Guertin answered this one nicely I think. If you're providing a
database access layer on top of the raw DB API, you should probably
also provide connection pooling. I bet there's a ticket for that.
> * Requiring DJANGO_SETTINGS_MODULE: I thought we fixed that so that
> you could do most non-app things without having to provide a full
> settings file[1]. Or did I misunderstand that?
That change improved the situation, but you still need the "from
django.conf import settings; settings.configure(...)" before
*importing* any other part of Django. That improves the situation,
but doesn't feel clean.
> * Escaping in templates: Christopher presents an *extremely* one-sided
> view of what's actually a fairly complex debate. There is no single
> obvious solution to escaping.
Possibly. What concerns me is that many in the Django team seemed to
think escaping is the responsibility of the template author, yet the
template author shouldn't be bothered with having to care about
programming logic. I've yet to meet a designer who understands XSS
attacks, but "x < y" they get. Maybe it's just me.
What probably wasn't clear enough in the post: I think the *benefits*
of a solid auto-escaping approach are obvious, not necessarily how
that's done.
> * The template system in general: the template system "doesn't scale
> down to a single developer"? I'm going to have to call BS on that,
> because we've seen plenty of one-man projects. The template tag
> decorators also make it a whole lot easier to write common sorts of
> tags.
I'm sorry, but if you have to scurry around multiple files just to
implement and use a parameterized reusable snippet of HTML markup,
because the template system doesn't trust you can use functions and
parameters, that's additional work you need to do. More code and
coupling between code and the templates.
If the template system simply allowed you to call functions, you
could reuse presentation logic that way, without having to register
tags. And you don't need to learn a whole new syntax for every
template tag.
> * The template system being "dumbed down" for designers? Going to call
> BS on that too. The real complaint here seems to be that the template
> system doesn't include a programming language, and personally I don't
> think it should. If there are things that someone runs into that they
> find themselves needing to use the same custom template tag over and
> over again in many different projects, then that needs to be submitted
> for possible inclusion in the default tags.
Allowing the full expressiveness of a programming language (with
control structure and all) is quite different from allowing real
expressions. Django intentionally does allow the embedding of Python
expressions, because the devs think/thought that designers would have
problem with the syntax, so for me calling it "intentionally dumbed
down" is not all that unfair.
I'm not saying that a dumbed down template system is a bad thing...
for example, for systems like TypePad etc where (untrusted) users
edit templates over the web, what you can do in templates absolutely
needs to be restricted, unless you want to allow them to take down
the system.
My point was that for teams that work on a web-app, where there's no
real distinction between programmers and template authors, this
actually does not help productivity.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
