@Amirouche:
Yes, sorry, I compared all django-composite instead of UrlCollections only...
Also the model app_labels detection is only relevant for model based
> UrlCollections and I think we should provide one feature at a time.
In django-viewsets, this is a feature of ModelViewSet. The basic ViewSet
has no app_label by default.
@Anssi:
Le lundi 28 janvier 2013 11:36:18 UTC+1, Anssi Kääriäinen a écrit :
>
> 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.
>
Of course, this is exactly why I designed this - one of my private
applications has a lot of models sharing the same views, and not only
simple CRUD views.
Using viewsets, this becomes:
class HistoryView(View):
[do something...]
class CustomModelViewSet(ModelViewSet):
excluded_views = ('create_view', 'update_view', 'delete_view')
def __init__(self, *args, **kwargs):
self.views['history_view'] = {
'view': HistoryView,
'pattern': r'history',
'name': 'history',
'kwargs': { custom view attributes and methods here },
}
super(self, CustomViewSet).__init__(*args, **kwargs)
from .models import Example
class ExampleViewSet(CustomModelViewSet):
model = Example
This syntax could be simplified (using namedtuple, for example), but this
is working.
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.
>
Hmm, you mean that writing GCBV for a specific use is hard?
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.
>
OK, so, discussion closed.
Regard,
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.
