On Tue, Mar 26, 2013 at 10:44 AM, meric <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
