http://www.twistedcommons.com/2008/12/how-django-works.html
There was a blog post several years ago that followed, in detail, the
life of a response with all the gory details. Unfortunately I can't
locate the link. The above page is brief, but has a nice picture that
is easy to follow.
A huge difference is that php code has access to just about every
thing in the global space of the script. It has access to headers,
cookies, path information, querystrings, and pretty much all the
information it might need. Django bundles that into a request object
and requires that you explicitly pass data about the request to your
code, In php you could access $_GET in an arbitrary function and it
would just work. The request.GET equivalent in Django is only
available if you pass it into the function.
Since code may be reused for the next request, it's possible for
changes to have polluted values from the first request if you
accidentally do something your shouldn't. This requires a little more
caution when writing your code, but is not difficult.
For example consider a function like:
def myfunc(listofstuff=[]):
listofstuff.append('I was called')
return listofstuff
If you call the function in the first request without a parameter
"myfunc()" it will default to an empty list, append "I was called" and
return a list with a single item ["I was called"], and everything will
work fine. The gotcha is that the empty list was defined when the
function was created, so the second request will get the -same- list,
which this time will not be empty, and the second call will return ["I
was called","I was called"].
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
