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 -~----------~----~----~----~------~----~------~--~---