Thanks for your reply. That was really helpful. I still haven't
decided which approach I'm going to take, but that helps balance the
sides for me. I suppose it will be obvious which I should have done
when I pick something and see how it works out :P
On Nov 19, 12:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
