Well.. let me add to this discussion as well :) 1) Loading 'static' templates is, imho, easily achieved. I wanted to lad them from the file system, but ended up putting static views in the database (using a custom, 15 lines of code template loader and a filter). The most astounding feature is the templates can extend each other.. and that there's something like back-up template. For example you have a template item.html, which shows an item, but if I want to give item 24 a special treatment, I can make a template_24.html that I put and the db (through a very rudimentary cms) and give item 24 a nice distinguishing look. Amazing, yes, this way of working with templates makes me happy ;) 2) Writing authentication is easy, I need it customized as well, writing from scratch goes faster then customizing it. (Apart from that, I use the built-in authentication for admins, and have a custom version for users). I think it is more important that it is extremely easy to work with things like middleware to built custom authentication than to have a built-in 100% satisfying version of it. After all Django is not a CMS, it's a framework. 3) I love manipulators (and as such I honestly don't see the need for something else). But I can understand others don't like them. Of course nothing is blocking you from using "bare-bones" html forms and just mangling with the resulting POST parameters in your view. 4) As stated above, the admin is just for data entry, not for end-users. (Though I like to misuse it to let end-user enter "advanced" data, which normally shouldn't be touched on a regular basis. 5) Well.. they're just python error stacks. But yes, not always intuitive. However, to really understand you workflow some form of logging is needed. And this is the first thing I added to Django, a basic way of logging. 6) Deployment is such a tiny bit of the actual development of a webapp that I couldn't care less how hellish this is. Once in place, however, updating should be easy. But this is not a problem. 7) No comment. Imho not important.
BUT.. there are some other problems I ran into. - Reverse lookup for urls doesn't work that well (still problematic for decorated views). I already altered it a bit to suit my needs (http://code.djangoproject.com/ticket/2615), but it would be great if, somehow, routes (http://routes.groovie.org/index.html) would be usable with Django. - Schema evolution, but that's obviously wip, just as the multiple db branch. The problem I now fid myself having is: using these branches, or waiting for the sqlalchemy branch to be usable.. - Documentation. Everyone seems to say how great it is, I find it lacking. I found myself looking at the source code quite often to find out the finer details of Django. The basics are indeed well discussed, but often I stumble over exact details. Moreover I've been using external documentation (the excellent http://www.b-list.org/) more that that available on the main site. As a final remark, I think it is important to see Django as a framework, not a complete CMS-like solution. I find it only logical to add custom helpers (or libraries whatever you want to call them). Most of the time this is rather easy. But sometimes not (url dispatching (though admittedly, I don't see how to decouple it. However, not hardcoding RegexURLResolver but instead allowing for a custom resolver by configuring might help.. But then one app might need multiple url-resolvers at the same time, as the admin app needs the RegexURLResolver... nasty..)), and it are these 'sometimes not' situations that things get troublesome. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~----------~----~----~----~------~----~------~--~---
