On Tue, 2008-11-18 at 19:46 -0800, stevedegrace wrote:
[...]
> I'm hoping someone more experienced with Django will explain the
> rationale for the preferred paradigm and show me where I have gone
> astray above, because I'm at a critical juncture in my own project...
> right now based on the above I'm planning to eschew all or almost all
> reverse mapping and instead plan out my URLs and directly generate
> URLs in all cases instead of mapping them from views and parameters à
> la reverse(). If I didn't understand the logic correctly and I'm
> making a mistake, I'd like to know.
There are quite a number of cases where URLs can change without running
amuk of the "cool URI's don't change" principle. There are also other
situations where reverse() is useful. A short list without thinking
about it too long:
(1) Whilst you're developing an application, you might decide that the
scheme you originally planned out doesn't quite work, so you'll change
it slightly. If you're using reverse(), you only have to make those
changes in one place.
(2) Your development machine setup could be different to where the
applications reside in production. For example, you might put your
weblog under blog/ in production, but when developing it with the local
development server, it will appear under /. Not having to change code to
handle that is effected by using reverse().
(3) If you're writing a reusable application, you don't know in advance
what the URL structure will be. So what is the URL to display a comment?
You don't know if you're working on the comments application, because
it's up to the end-user to decide where to put it in their URL space.
Using reverse() means that you can use an essentially opaque name for
the pattern that doesn't affect the final URL that is produced. It's a
semi-significant flaw in Django at the moment that you *can't* do this
for the admin interface, so sending the user from some page to the admin
page for something else requires a bit of awkward hoop jumping (it's
possible, but fiddly and a little fragile).
(4) Sometimes reorganisation happens for other, external reasons. "Cool
URI's don't change" is actually woefully mistitled (or frighfully
optimistic and practically unrealistic). URLs, particularly, change
quite often. However due to the wonders of HTTP redirects the old URLs
can often be made accessible. They redirect to the new canonical URL. If
that sort of situation arises, you'll often use reverse() to produce the
canonical URL and set up a bunch of redirects from the older URLs to the
canonical ones. The older ones are still accessible, but any
HTTP-understanding client will know to go to the newer ones in future
(due to a 301 response code, for example).
(5) Using reverse() is often a lot more explicit than a writing the URL
out in full. Which of these is more immediately readable?
(a) /blog/archives/full-text/%s/ % (input1,)
(b) reverse("full-archive", kwargs = {"issue-number": input1})
(and, yes, I intentionally used an ambiguous variable name. That happens
sometimes in real code, too.) A developer reading the second call isn't
going to be wondering what all the magic numbers mean, even if they're
extracted from variables.
All that being said, some people choose not to use reverse() or the
"url" template tag. And that's fine, too. If it makes your life easier,
use them. If it doesn't, don't use it.
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?hl=en
-~----------~----~----~----~------~----~------~--~---
