On 8/22/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: > 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)
Maybe this is just a semantic point, but I think we need to be clear on the distinction between "the Django framework" and "Django applications bundled with the Django framework". And, again, you *can* use the Django admin with other ORMs. There are people using the Django admin app on top of Rails apps, so using it on top of another Python ORM shouldn't be too terribly hard. > 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. See my other reply for my thinking on 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. So let's brainstorm solutions. What *would* feel clean to you? > 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. Again, I think that if there are common cases for which we don't provide tags, that's a separate matter (and can be remedied by putting in a ticket, pointing out the use case, and -- ideally -- also supplying a patch). Escaping, though, is much more complicated. The term "escaping" doesn't even have much meaning in the context of some of the things you can do (and that people *are* doing) with Django's template system -- what sort of "escaping" would be appropriate for, say, LaTeX output? The fact that the template system doesn't tie itself to only being able to output (X)HTML makes this a muddy question, and the fact that there are lots of filters people use (like the ones in django.contrib.markup) which are meant to output unescaped HTML makes it even muddier. Reasons like that are why escaping has been such a long, drawn-out debate. > 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 benefits of auto-escaping most variables when the output format is an SGML-derived markup language are obvious. Granted, that's a lot of use cases, but since we're clarifying... ;) > 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. It's not a matter of "the template system doesn't trust you can use functions and parameters". The template system doesn't assume template authors are idiots, and the complexity of some of the built-in tags should make that obvious. The template system, however, isn't a programming languages, and that's by design. > 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. I mean nothing personal by this, but if you're writing multiple tags which do similar things but use significantly different syntaxes, that's not a problem with the template system. And again, if we're talking about a common use case where a built-in tag or tag decorator isn't sufficient, then let's come up with ways to fix it. Having reusable bits of content doesn't require a full programming language. > 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. There's a difference between "dumbing down" and "you shouldn't have to learn Python programming to write a template". The Django template system does its best to provide constructs for common types of presentational logic (if/else, for loops, etc.), but again, this *doesn't* require that the template syntax accept arbitrary Python expressions. > 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. I'm still not buying it. I've worked on applications as part of a team, and I've written a couple as solo jobs, and I've never seen the template system getting in the way. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
