Hello Anssi, Amirouche, and anyone else, Glad to see I am not the only one that got this idea (nearly at the same time, btw)!
Le samedi 26 janvier 2013 11:49:34 UTC+1, Amirouche B. a écrit : > > It's very interesting and it might be why a similar thing exists in the > admin but not pluggable yet. > > There is a ticket for this issue: > https://code.djangoproject.com/ticket/16213 > OK. I guess we discuss in this google group until we come up to some design decisions, then write it to the ticket? I made another implementation of this > https://github.com/django-composite/django-composite/blob/master/composite/urls.py > Please have a look at it, I'll do the same with multiviews and viewsets and > to try to advance the discussion further maybe merge the three of them ? > Excellent! I spent two hours reading the code of both multiviews and composite. Here is what I understood: What's in common between multiviews, composite, and viewsets: - Views are grouped in a class. - Each view is tied to an URL pattern. - All URL patterns of a group of views are accessible using nearly the same syntax: GroupOfViews.urls() for multiviews, url('', include(GroupOfViews().urls())) for composite and url('', include(GroupOfViews().urls)) for viewsets. Multiviews Pros: - Simple. Cons: - Uses inspect to find views. Too "magic" IMO. - Requires to define a form, specify the namespace and template names (example: https://github.com/akaariai/multiviews/blob/master/views.py#L96 ). - The views defined are very simple reimplementations of GCBV; and of course, not extensible. - No GCBV support. Composite Pros: - Powerful; a complete framework to the glory of Python (write less HTML/CSS/JS, more Python!) and DRY. - Views directly have name and path attributes to avoid writing them inside urls.py. Cons: - Complex. - Highly misleading names (especially Widget…). - No application namespace detection. - Can't be easily merged in Django (I know, composite was not designed for this purpose). Viewsets Pros: - Simple. - Designed to be extensible (even though it could be better). - Automatic application namespace based on model app_labels. - PEP8 compliance and Python3 support ;o) Cons: - No function-based views support (could be fixed in two lines). - Uses an awkward dict to define views, url names and patterns. By the way, I really liked in *composite* the idea of setting url names and patterns as class-based view attributes. Maybe the best idea of all this discussion; could this become a core feature, as well as "template_name" and "get_template_name"? Thanks, Bertrand -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from 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.
