Héllo Anssi,
2013/1/31 Anssi Kääriäinen <anssi.kaariai...@thl.fi>
> On 28 tammi, 21:08, Bertrand Bordage <bordage.bertr...@gmail.com>
> wrote:
> > > 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.
>
> My intention wasn't to stop discussion about this feature,
Sorry, I'm busy so I was waiting for the weekend to answer to posts.
> just to say
> that it is unlikely to get into Django until there is a proven way to
> implement this feature. And by proven I mean there is a 3rd party app
> that has enough users.
>
Yes...
> It might be that there isn't a single approach to this, and in that
> case multiple different implementations outside core is the way to go.
> If there is something common between most implementations, then core/
> contrib is the right place for those shared bits.
>
> Looking at the discussion history maybe finding those shared bits was
> all you were trying to do...
>
Yes
To give a bit of background on my take on this, it was while experimenting
on a rewrite of the admin that
lead me to UrlCollection.
CompositeView is one part which deals with Composition inside a view and
another part
is UrlCollection which deals with urls and thus views. Both are not needed
for the admin
to work but since it's a rewrite I wanted to take the time to extract
interesting pieces that could
be reused outside of the admin. The other part of the admin that is not
extracted from the admin yet,
is a class that deals with Forms and Formsets so that both ForeignKey and
M2M can be created in one
page.
So it's likely to be a useful pattern...
> So, what I want is:
> - To use self of the view collection class to bind data to templates
> (that is, one instance per request).
>
I read one instance of «view collection» per request otherwise you break
thread safety
- To use self to call shared functionality between views. That is, I
> want to implement both history_view() and the update_view() in the
> same class, so that both of them can call shared methods.
>
This can be achieved with inheritance, do you have an example of sharing
data between views
that can not be achieved with View init_kwargs ?
Actually first version of UrlCollection was binding UrlCollection made
available a property on every view part of it,
that was returning a new instance of UrlCollection when accessed... Thus it
was possible to do:
class MyView(View):
def get_queryset(self, *args, **kwargs):
return dict('queryset', self.collection.get_queryset())
But I stripped that because not efficient and not needed because I think
it's possible to do everything you need through init_kwargs.
> If I understand this pattern correctly
>
> 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)
>
> here HistoryView and UpdateView can't share functionality?
>
Yes.
> I think we are aiming for different use cases, the viewset pattern
> seems to be about tying together multiple existing views, while the
> MultiViews pattern is about creating the views in a single class.
>
Can you describe or give an example of MultiView usage ? Here is an dull
example of
UrlCollection<https://github.com/django-composite/example-app/blob/master/delicatewebizen/favorites/urls.py#L7>,
there not declarative API since it's meant to be the base for anything
fancier ;)
Also I still don't agree with the naming, except if I didn't understand
this part, those projects are dealing with views through defining urls for
them. So the Collection class should be UrlCollection or something not
ViewCollection or MultiView.
Regards,
Amirouche
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
