Let me explain my use case. I have some CRUD views for similarly behaving objects, and also some additional views (history view for example). The add, modify and delete views have shared logic. And of course, there is shared logic between the objects.
So, I'd like to create a base generic view for these objects. I want to have my generic view, the use case is somewhat specialised... If I can create my generic view from scratch, then I know the view is going to match my use case. The single class - single view pattern doesn't work for this use case. It isn't easy to have the shared functionality between objects + shared functionality between add, modify and delete views. It is possible, but the code wont look nice. There are multiple ways to implement the view collection pattern. It isn't at all obvious that there is one right way to do this. If it turns out there is a best way to do view collections, then integrate that into core. Or, if there is some shared functionality each implementation needs to do, then that shared functionality should be in core. This all assuming a sizeable portion of Django users actually want to use view collections. I know this answer isn't wanted... But testing different implementations outside Django core/contrib is IMHO the right way to go. - Anssi On 28 tammi, 08:08, "Amirouche B." <[email protected]> wrote: > > 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.
