On Tue, Mar 26, 2013 at 10:44 AM, meric <meric...@gmail.com> wrote: > Thinking through Adrian's post and mine above, it appears to be a trade > off between coupling in the framework and increased responsibility for user > views code. Personally I would opt for the former, because IMHO the idea of > a framework is to reduce responsibility of user code and promoting same > sets of design patterns for common problems (rather than each similar > program having different adhoc ways to deal with the same problems I.e > rather than having different ways people would implement a catch all view, > have views send the same signal if the given arguments were not > interpretable.) first before anything else, otherwise what else can a > framework provide?.
Even though I suggested the use of a catch-all view for handling multiple objects in the beginning of the thread, I now see the value of moving this to urls.py. For more complex websites and scenarios, some patterns may emerge that lead to such a number of possibilities that at some point, from a design perspective, you start wondering if you're not packing too much routing into the views (with a catch-all view) when they should be handled by the URL routing module. Previously -1, now +1 on this idea. Cheers, AT -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
