>
> 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.
>
> I am in favor of using the include('path', GroupOfUrls.url()) syntax
>
>
> 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).
>
> Those are what UrlCollection are meant for.
>
> - 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.
>
> The part was dropped because a) it can be implemented in user code b) It's
not «relevant» in the composite framework c) path makes view bound to urls
which makes it impossible to add a view in different places (loose
coupling...) and it is not relevant to UrlCollection, UrlCollection is only
the urls.py file.
Cons:
>
> - Complex.
>
> Only the urls.py file is takes part in the UrlCollection feature
>
> - Highly misleading names (especially Widget…).
>
> this is not related to UrlCollection
>
> - No application namespace detection.
>
>
> - Can't be easily merged in Django (I know, composite was not designed
> for this purpose).
>
> Actually it is, but not this way.
>
> 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.
>
> I think ViewSets is the nearest thing to what could be merged, thus we
should use it. Also the model app_labels detection is only relevant for
model based UrlCollections and I think we should provide one feature at a
time.
Also what do you think about nested UrlCollection (or nested GroupOfViews)
basically make it possible to include other GroupOfView in a GroupView
>
>
> By the way, I really liked in *composite* the idea of setting url names
> and patterns as class-based view attributes.
>
No, it's not a good idea, see above.
> Maybe the best idea of all this discussion; could this become a core
> feature, as well as "template_name" and "get_template_name"?
>
In composite what I do, is bound the *View classes to the GroupOfViews
class then instantiate the bound class so that user code can override which
view is instantiated this way it's possible to change templates easily.
Adding a hook in GroupOfViews to override templates for several Views is
prone to error.
It lakes tests and documentation of course. I'll try to do a push to
Viewsets something if you did not already do it. I think getting an
external app up and running is the best thing to do.
Regards
--
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.
