On Fri, 2006-09-29 at 10:26 +0900, Sean Schertell wrote:
> Hi Guys,
>
> I just wanted to share with the community my personal experience with
> Django in the hopes that maybe some of my petty gripes might be
> somehow helpful. Before doing that, I have to thank everyone in the
> community for being so helpful and just so damn nice! Thanks so much
> to all on this list and on the IRC channel.
Sorry to hear you're not completely satisfied, but thanks for taking the
time to write this regardless. It should be food for thought.
No doubt this will turn into a long thread and possibly not all relating
to your original issues, but some of your problems seems valid (others
seem to be a matter of perspective and experience and so not really
universally "fixable" in any real way). On the whole, though, it's good
to hear what people think.
A couple of brief comments below:
[...]
> (1) Clean modular design with 'apps' that can be imported into
> 'projects'
>
> (2) Included libraries for things like authentication
>
> (3) Reasonably easy forms with form wrappers/manipulators
>
> (4) The free Admin section!
>
> (5) Overall really polished look and feel -- even the error pages
>
> (6) Super simple deployment with mod_python
>
> (7) Opinionated design decisions start you off with something
> sensible so you don't have to reinvent the wheel for things like
> naming conventions or directory structure.
>
> ----------
>
> But I'm very sorry to say that one by one, all of these things turned
> out to be not so great after all. Here's what I found after six weeks
> of struggling to build a site in Django that would have taken a week
> or so in PHP.
That's probably an experience thing. Although Django does advertise
"stupidly fast" or something like that, I would prefer that we thought
of that "on average". Any new system takes a little while to ramp up.
That being said, the initial learning curve, particularly for the
corporate-style user, is something we are working on actively and should
continue to do so.
> ----------
>
> (1) The clean modular apps aren't totally decoupled because they
> still have to use the project's template directory and css (which
> makes sense perhaps but complicates things for what I'm trying to
> achieve).
Not sure why you didn't think you could put these inside the app
directories. It's possible.
> More importantly, there's no built-in facility for
> rendering templates which are just static pages. Yes I know there's
> flatpages and templatepages but it would be a lot nicer if Django
> just served up the template in the absence of a url-routed view. I
> ended up writing my own little app to do this which took the better
> part of a day. So it took extra work to accomplish something as
> simple as serving a static html page.
It's not clear from this what you wanted to do that isn't covered by
flatpages of TemplatePages or a small variation thereof. But if there's
something you really needed here and couldn't do, I agree that could be
frustrating.
> (2) This is a biggie for me. I can't believe that the authentication
> module forces you to use hard coded urls for login/logout pages --
> that's just maddening!
Again, this isn't universally correct, so it would be interesting to
hear what your specific case was. You can have any URL you like being
the login URL (or even multiple ones -- so you can have a login box on
every page if you want) and you can redirect to wherever you like
afterwards. So customisable entry and exit points -- what other
flexibility is useful here?
The auth system is not the best documented piece of Django, though.
Improvements there will be welcomed by many people, I'm sure.
> So if you want to do it your own way, you have
> to totally roll your own authentication from scratch. More work. I
> ended up hiring a guy to write a basic auth system that lets me set
> my own urls.
>
> (3) FormWrappers are great until you need to do anything even
> slightly different from the django prescribed method, then you have
> to use custom manipulators which I found to be a giant pain in the
> ass. I spent literally several days working on one form (yes it's a
> complex form -- but 4 days is ridiculous). The first thing that threw
> me was that I wanted to use a more traditional method of inputting a
> date -- just three pulldown menus for month, date, year. Instead of
> providing some simple facility to let you override parts of the
> standard manipulators, as soon as you find something you want to do
> that isn't included, you have to write a whole custom manipulator for
> it.
Manipulators are a different way of thinking and it seems not entirely
intuitive to everybody. This is certainly a stumbling block for many and
one reason we are trying to improve them and remove a lot of the
complexity and restrictions they impose at the moment.
I suspect this is partly an experience/learning curve item, but it is
something we are trying to make easier.
> (4) The admin section is certainly pretty enough for production use
> -- but it isn't flexible enough in my opinion. Take my 3-pulldown
> menus for inputting a date as an example. How would you go about
> doing that in the admin section? I suppose there's probably some way
> -- but this is another example of django getting in the way -- adding
> extra work where I'd hoped it would be reducing work. After
> identifying a few things that wouldn't work easily with the free
> admin section, it looked like the easiest solution was to do my own
> custom admin section rather than try to sculpt the django admin
> section into what I wanted.
I see this as an expectations thing (and something where Django PR can
possibly improve).
This may be a point of view thing (on my part): I don't see the admin
interface as something you expose to the user. It's a basic data-entry
screen for things that work on a per-model basis. If you want more
cross-model entry or customisation, you are writing your own forms,
because there are so many ways to do this.
I sometimes wish we wouldn't hold the admin interface up as such a
glorious thing all the time ("and then he was struck down by lightning
and a little note fell from the sky saying 'some guy in Chicago just
called'!") just because it does set slightly unrealistic expectations.
It's wonderful for its purpose, but that purpose is not all-encompassing
(thankfully). We can work on this.
> (5) The polish is very nice -- no question. But I was disappointed to
> discover that many of those sexy error messages didn't reveal *my*
> coding error but just reported problems as they occurred in the
> django stack. So I was often left to guess about what part of my code
> was causing the issue.
Valid point.
> (6) Not really a django issue but disappointing nonetheless. If you
> want to deploy to a cpanel server (which is stuck in the 1900's using
> Apache 1.3), you'll have to mod_proxy out to another web server such
> as Lighttpd with FastCGI. That's exactly how Rails apps are typically
> deployed and one of the reasons I went hunting for an alternative. So
> much for the easy deployment advantage.
Yep. Not really a Django thing. Something we can try to help out with in
Documentation in any case, but we cannot magically upgrade technology
from other projects. Apache 2.0 is over four years old now; it isn't
unreasonable to require it for the simplest installation.
To run any sort of process like Django or Ruby on Rails or TurboGears,
you are going to need either an in-process interpreter like mod-python
or a persistent process handler like fastcgi. You can't run these things
as CGI, it just doesn't work performance-wise. So there's a limit to how
simple we can make this, given we are relying on other components at
some point.
> (7) The first thing I did after creating a new project was to
> organize the directory structure more sensibly. Littering the top
> level of your project with things like manage.py and urls.py just
> isn't very clean. So I started by searching the list archives, posted
> some questions of my own and just generally spent a lot more work on
> this issue than a framework should require in my opinion.
Come one. This is not a very valid complaint.
If you feel that four files (__init__.py, manage.py, settings.py,
urls.py) is littering, then it might be hard to find a framework that
satisfies you. Since settings.py and urls.py can go anywhere, you can
cut it down to two. And since manage.py isn't even really needed (you
can get by without it if you wish), you could cut it down to one. But
I'm just not sure this is a real issue. I cannot think of any
professional project I've worked on or with that had less than four
files in the top level directory.
Best wishes with your future development, whatever it may use and thanks
for the feedback.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
