Why I'm giving up on Django
Sean Schertell
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.
So here's the thing... I came from a background of PHP and then Ruby
on Rails. I was drawn to Django because it seems more modular and a
better match for my goal of creating web *sites* with apps the live
*in* the sites. Rails doesn't really work that way at all. And PHP?
-- well, you know. PHP lends itself to a style of coding that is so
not DRY, it's like coding underwater.
So I went on a quest to find a well-polished, easy to use framework
that is modular, object oriented, does the basics like database
abstraction and form validation, is easy to deploy, and most
importantly: *doesn't get in my way*. After exploring lots of
options, I settled on Django. I bought a book on Python, went though
the Django tutorials, read the docs, etc. It all looked fantastic!
The things I was most excited about were:
(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.
----------
(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). 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.
(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! 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.
(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.
(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.
(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.
(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.
So at the end of the day, my experience with Django started off with
a *lot* of excitement. I was thrilled because it seemed I'd found
something that met my needs exactly. But in actual usage, I found
that using django to build a website the way *I* want to build my
website ended up being more work than if I'd just coded it by hand in
PHP.
If there's a take home point to all this it would be this: I feel
that a good web framework should *above all else* not get in your
way. It should start off with a very sensible way of doing things and
let you override the *bits* that you need to override (not forcing
you to custom write your entire form wrapper in order to change just
one element for example).
Anyway, I know Django is still young and I'll probably be back for a
second look as it matures. I'm excited to see the upcoming
replacement system for form wrappers/manipulators. I suspect that
alone will be a major improvement.
Thanks again to all. I'll see you soon ;-)
Sean
Adrian Holovaty
> So at the end of the day, my experience with Django started off with
> a *lot* of excitement. I was thrilled because it seemed I'd found
> something that met my needs exactly. But in actual usage, I found
> that using django to build a website the way *I* want to build my
> website ended up being more work than if I'd just coded it by hand in
> PHP.
Sounds like Django in its current incarnation isn't for you. Thanks
for giving it a shot, thanks for the great feedback, and check out
Django again after a while. Have fun with the PHP!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Malcolm Tredinnick
> 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
Kenneth Gonsalves
On 29-Sep-06, at 6:56 AM, Sean Schertell wrote:
> 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
all the 7 points you mention have been bugging me for some time now.
but I am not giving up on django for the simple reason that all of
them are actively in the process of being fixed - as a casual look at
the devel list would show you. In fact right now I am struggling with
an app which I thought would take me 20 minutes - but has crossed a
day and a half already because of these issues. But once its done -
it'll stay done and i can sleep at night. You *have* noticed that the
django community rocks - but dont realise that that is the prime
reason why you shouldnt give up on Django
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Don Arbow
>
> (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! 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.
This isn't such a roadblock. There are many places in Django where
you can ignore the abstractions and use the low level code. In less
than 5 minutes, I wrote my own login/logout methods and called out to
the basic auth methods when needed:
from django.contrib import auth
from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response
def login(request):
if request.POST:
username = request.POST.get('username', None)
password = request.POST.get('password', None)
user = auth.authenticate(username=username,password=password)
if user :
if not user.isactive:
return render_to_response('user/login.html'
{'message':'This account is not active.'})
auth.login(request, user)
return HttpResponseRedirect('/')
return render_to_response('user/login.html',
{'message':'Please enter a username and password.'})
def logout(request):
auth.logout(request)
return HttpReponseRedirect('/')
Don
James Bennett
> 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).
No, they don't.
http://www.djangoproject.com/documentation/templates_python/#loader-types
> (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
So file a ticket; the login/logout URLs are a bit of a wart, and we
could certainly stand to improve that situation.
> (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.
There's a reason why we're working on a replacement for the
manipulator system :)
> (4) The admin section is certainly pretty enough for production use
> -- but it isn't flexible enough in my opinion.
I don't think it's ever going to be "flexible enough" or "customizable
enough" for every conceivable use. It's just plain impossible. Right
now, I think we do a good job of getting to, or at least close to, the
80% mark.
> (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.
Tracebacks are a really hard thing to handle well in an application
stack with more than a couple of components; generally the debug pages
are nice, though, because they give you the local vars at each level
-- when (as is often the case) an error occurred because some code
didn't raise an exception but *did* do something it shouldn't have,
having the local vars can be a lifesaver.
> (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.
There's not much that can be done about this; as Malcolm pointed out,
Apache 2 has been around for almost half a decade, and so if you want
to use Django under mod_python you need Apache 2.
> (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.
What would be cleaner? Also, the ROOT_URLCONF setting lets you put
your root URLs file anywhere on your Python path, and if you don't
like manage.py, just use django-admin.py with the
DJANGO_SETTINGS_MODULE environment variable or pass it the explicit
'settings' argument.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Michael Radziej
>
> (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.
This is recognized. Well, in the end every framework will give
you a frame and make things that fit it easy, but somewhere it
ends, and then your down to yourself. I didn't find manipulators
particularly hard to use once you've learned how they work and
what parts you need. I only wished I wouldn't have first tried to
derive from the automatic manipulators. It seems to be so much
easier just to derive from django.forms.Manipulator instead. And
I'm really looking forward to the "new way" with model
validation, bound forms etc.
Now, I still can deal well with current manipulators, but there's
one major hassle:
Manipulators get very hard to use when you deal with inline
editing on yourself, because all this inline collection stuff is
not very flexible and heavily underdocumented. Either I'm too
stupid, or there's the really dark djungle of django.
Another point is that I wished Django had SqlAlchemy as ORM. The
built-in just is too naive for my taste. But there's already a
branch starting on SqlAlchemy integration.
Looking into other frameworks, I give a lot on good
documentation, and I hate when I have to dig into the source to
find out details about the API. I just couldn't find any
competitor that comes any close to django in this aspect. I'm
with django.
Michael
Dagur Ammendrup
| <input type="hidden" name="next" value ="{% if next %}{{ next }}{% else %}/{% endif %}" /> |
rikl...@gmail.com
daniel...@gmail.com
> Tracebacks are a really hard thing to handle well in an application
> stack with more than a couple of components; generally the debug pages
> are nice, though, because they give you the local vars at each level
> -- when (as is often the case) an error occurred because some code
> didn't raise an exception but *did* do something it shouldn't have,
> having the local vars can be a lifesaver.
Here's my anecdote on that.
Even though it was literally staring me in the face, it took me AGES to
discover that the error dump page is actually interactive and has
little sections that expand and collapse.
I kept running into error messages which told me about exceptions in
the Django source code (this is the top part of the error page) and I
kept thinking "well, where's the bloody use in that??? I want to know
what MY error was! Grmbl.".
It took me at least two weeks (yes, sometimes I really *am* that dense)
until I scrolled down and explored and figured out that there was the
information that I had been wanting all along.
Somehow, the styles, fonts and layout choices of the error page (lots
of text, lots of grey) made it totally non-intuitive for me that it was
interactive.
Oh, well.
Daniel
Holger Schurig
> exceptions in the Django source code (this is the top part of
> the error page) and I kept thinking "well, where's the bloody
> use in that??? I want to know what MY error was! Grmbl.".
Django your easily find out if a module name in it's output
starts with django. If yes, it could use CSS to make it lighter
or gray or whatever.
In this case, the user-modules (e.g. urls.py or views.py) would
stand out.
Easier for the eye to catch :-)
Ivan Sagalaev
> Instead of
> providing some simple facility to let you override parts of the
> standard manipulators
In fact you can do just that. Though it's not clearly documented. I
recently wrote about it here:
http://groups.google.com/group/django-users/tree/browse_frm/thread/f9c23a420303d03f/f1635e9a27c6ae68?rnum=11&q=seeking+clarification&_done=%2Fgroup%2Fdjango-users%2Fbrowse_frm%2Fthread%2Ff9c23a420303d03f%2F5cc17ee0636e3549%3Ftvc%3D1%26q%3Dseeking+clarification%26#doc_f1635e9a27c6ae68
mamcxyz
with ASP.NET (I'm certified by MS, if that show my commitment) and try
first with Clastle (a try on rails for .NET, but with the non-sense of
java-like framework) I found django.
I hate:
- Deployment. I work on Delphi and the idea of put a EXE and all is
working right (tm) is a feeling I lost with python on hosting. In the
end, I singup at jodohost mainly because was cheap, get VPS (but
unfortunally Centos 3/4, still I'm unable to install easily this
thing... I hate this point more and more)
I hate, hate, hate it. I build my first site in 1 1/2. 1/2 months was
coding (with not serious python experience) the other 1/2 with html,
desing and css and the rest is for deploying.
But this is a situation of python. So is not a fault of django..
(However, a setup script what download the prerequisites can be sooo
handy... any idea?)
- I dislike the indirection to run django class... the thing about run
python manage.py shell to really touch the classes... is not very
"pythonic", or mainly, convenient.
But is a minor thing...
- I don't understand the complexity of forms manipulators. But I worked
around it. Ok, is not that complex, but is not intuitive.
In the other hand, the template system is very powerfull (but I think
is not so friendly for people that only know the use of html desingners
like dreamweaver. But I before start to build things using topstyle, so
is great for me).
I like the OR mapper. Very cool. I like the url system ... but use
regex can be a little.. complex. I think must exist a auto-routing
mechanism like:
sample/_SLUG/_NUMBERS/_MONTHNAME
or something like... but not a big deal. Learn regex is a must.
I know before enter on this that Django is a stack and have their way.
I read all the docs before start the project and read the newsgrousp.
Dudes, do something about deployment and that all for me ;). I mean, a
installer or script that generate the configs for apache or lighttpd,
check dependencies (like PIL... I hate not have a working PIL :(, like
easy_install, db bindings, etc...)
I can help on this, only for the sake not walk again the painfull
experience on setup a VPS from scratch...
Don Arbow
> - I dislike the indirection to run django class... the thing about run
> python manage.py shell to really touch the classes... is not very
> "pythonic", or mainly, convenient.
How can the python shell not be pythonic?
Don
DavidA
daniel...@gmail.com wrote:
>
> Here's my anecdote on that.
>
> Even though it was literally staring me in the face, it took me AGES to
> discover that the error dump page is actually interactive and has
> little sections that expand and collapse.
> I kept running into error messages which told me about exceptions in
> the Django source code (this is the top part of the error page) and I
> kept thinking "well, where's the bloody use in that??? I want to know
> what MY error was! Grmbl.".
>
> It took me at least two weeks (yes, sometimes I really *am* that dense)
> until I scrolled down and explored and figured out that there was the
> information that I had been wanting all along.
> Somehow, the styles, fonts and layout choices of the error page (lots
> of text, lots of grey) made it totally non-intuitive for me that it was
> interactive.
You're not the only one. It took me quite a while to figure that out,
too. In fact, I only figured it out because I saw someone post a
screenshot to a blog one time and I was thinking "why does his
traceback show more source lines and the variable values?! Its not
fair!"
I was always afraid to admit that it took me so long to figure it out.
But now that you've come out of the closet...
I agree that the UI could be tweaked to make it more obvious, like
changing "Local vars" to "Click here to show local vars". I also don't
understand why the code and variables are hidden by default (which is
where I want to look 99% of the time) and the request and settings
information is expanded (where I end up finding the answer about 1% of
the time).
But pointing out these little things is the first part of the process
of making Django better. And it _does_ keep getting better, even over
the short period of time that I've been using it.
-Dave
Ivan Sagalaev
> I agree that the UI could be tweaked to make it more obvious, like
> changing "Local vars" to "Click here to show local vars".
This will just make this pile of text look more scary :-). You and
Daniel didn't read it in the first place so changing text won't help.
But what will help is using either actual standard buttons that are
recognizable as being controls for clicking or styling text to look like
a button (with colored 3-d looking border).
Wilson Miner
images for the debug pages. I wanted them to be completely
self-contained, which is why we used the unicode glyph for the
disclosure triangle (a pretty universal UI indicator) to indicate that
those sections could be expanded.
Baurzhan Ismagulov
On Fri, Sep 29, 2006 at 07:43:49AM -0700, mamcxyz wrote:
> - Deployment. I work on Delphi and the idea of put a EXE and all is
> working right (tm) is a feeling I lost with python on hosting.
So what about writing a small script that will do this for you?
Something like
tar cC /localdir/myprj . |ssh host tar xC /remotedir/myprj
FWIW, I create a Debian package of my project and install it on the
server.
With kind regards,
Baurzhan.
mamcxyz
Specially when is necesary setup other dependencies.... I know some
things can not be automated easily because the diversity of linux
distros, but something in the lines to show what is need to deploy is a
*good* start.
Don Arbow
>
> That was actually a conscious decision to keep from needing support
> images for the debug pages. I wanted them to be completely
> self-contained, which is why we used the unicode glyph for the
> disclosure triangle (a pretty universal UI indicator) to indicate that
> those sections could be expanded.
When I first saw them, I thought they were bullets rather than
disclosure triangles. Mainly because the lines with these triangles
are spaced further apart. Having used the Mac for quite awhile, items
with disclosure triangles are adjacent, items that are disclosed are
further apart with a downward arrow.
Don
Ivan Sagalaev
> That was actually a conscious decision to keep from needing support
> images for the debug pages. I wanted them to be completely
> self-contained, which is why we used the unicode glyph for the
> disclosure triangle (a pretty universal UI indicator) to indicate that
> those sections could be expanded.
I didn't propose any images. I mean either this:
<button onclick="..">Local vars</button>
or this:
<a href=".." onclick=".." class="button">Local vars</a>
a.button {
border-style: solid; border-width: 1px;
border-color: #DDD #666 #666 #DDD;
}
I prefer an actual <button> since it's more accessible and more
recognizable.
Norjee
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.
Milton Waddams
sites I developed, I was able to get the fastcgi module installed and
the site runs fine (has had some decent traffic levels).
ian
This is very interesting and would maybe make a great tutorial ...here
is my shot at how you would do this and create a hello-world application
for Django (please correct the errors):
1. Create a directory hello-world-1.0.0 (more on debian package naming
at Debian New Maintainers' Guide:
http://www.us.debian.org/doc/maint-guide/) and put all files in it
2.Debian packages use makefiles (Makefile) instead of Python Distutils
(Distributing Python Modules: http://docs.python.org/dist/dist.html) so
we have to write a Makefile to act as an interface between the Debian
package system and our setup.py.
So create a file called "Makefile" containing this:
all:
python2.4 setup.py build
clean:
python2.4 setup.py clean --all
install:
python2.4 setup.py install
3. In a terminal run dh_make:
vern@zionmainframe:~/hello-world-1.0.0$ dh_make -e i...@inpa.gov.br
This will output some info to the screen (choose single binary as the
package type) and it will then create a debian/ directory below the
hello-world-1.0.0 directory. The key files in this directory are control
and rules. In 'control' it's a "fill in the blanks" work and in 'rules'
it's essentially a matter of removing unwanted/unnecessary code
Because our app is 100% Python we have 100% architecture
independence...so the bottom of the rules file should look like:
# Build architecture-independent files here.
binary-indep: build install
dh_testdir
dh_testroot
dh_installchangelogs
dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
binary-arch: build install
4.After step 3 we have to actually build the package now:
vern@zionmainframe:~/hello-world-1.0.0$ dpkg-buildpackage -rfakeroot
The parent directory should now have a file called
hello-world_1.0.0-1_all.deb which is your Debian package to install
where you like with dpkg -i hello-world_1.0.0-1_all.deb
[]'s
--
Ian Lawrence
Centre for Bioinformatics
INSTITUTO NACIONAL DE PESQUISAS DA AMAZÔNIA-INPA
RUA ANDRÉ ARAÚJO N º .2936 , BAIRRO DO ALEIXO
MANAUS-AMAZONAS-BRAZIL
Research Program in Biodiversity
http://ppbio.inpa.gov.br
PHONE: 055-92-3643-3358
CEP. 69011 -970
| Please do not send me documents in a closed
| format.(*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.html,*.txt)
http://www.gnu.org/philosophy/no-word-attachments.html
"We are all in the gutter, but some of us are looking at the stars."
Jon Atkinson
reasearch next week to package up my app, but hopefully I won't have
to now.
--Jon