Hi Kye,
Sorry for mispelling your name above, but it's a really long thread and
non-native. And I can tell, there's rarely a better way than discussing in
foreign languages to make a nice little fool of myself xD This time I will
share my story with CBV, a story with love, and code and aggressive design
patterns in it. This is all because one of you consulting for yourlabs made
a comment about my shitty JS code: it was non aggressive. I've been working
that state of mind and then ...
The first violation I made to any bare common sense was to add support for
magical getters ... now view.url can return the result of view.get_url()
... And then I went on breaking Python by adding support in the type as
well ... now View.url can also return the result of View.get_url()
... At the price of thread safety, I guess I'm lucky it was always an easy
fix "just use the right variable you're allowed to but keep on refactoring"
... And then it became even more obscure when the magical getter also was
able to detect if {V,v}iew.get_url(view) would have not returned anything,
but did set {V,v}iew.url as attribute ... now caching became absolutely
free ...
... And then added a Controller in-between Model and its set of View ...
now Django knows MVC and can generate object level menus with efficient
permission management thanks to the Django permission backend that has so
many plugins or whatever implementation you put to override per controller
or view ...
... And then added a rich experience from out of the box templates because
why not after all django-webpack-loader by @alihazemfarouk is dope to
upgrade front end development workflow to a level like Python ...
... Don't ask what front-end framework cause what matters to me is the
practice of an modular development workflow, not which JS framework ...
... All this because a friend of mine who didn't understand Django, didn't
understand why we should hardcode menu HTML code, and cried in my laps for
help to refactor for days, the first name for the Controller class was
"Drycrud", do you imagine, instanciating a new Drycrud object ? Even more
obscure. Well at least it's named Router for now but in its final version
it needs to be called Controller because it sits between the Model and it's
set of class Based views ...
... So the generic ListView for example is like:
class ListView(mixins.ListMixin, mixins.SearchMixin, mixins.FilterMixin,
mixins.TableMixin, mixins.ObjectsMixin, TemplateView):
def get_object_list(self):
if self.filterset:
self.object_list = self.filterset.qs
else:
self.object_list = self.queryset
if self.search_form:
self.object_list = self.search_form.get_queryset()
return self.object_list
def get_listactions(self):
return self.controller.get_menu('list_action', self.request)
The view.listactions variable allows a view to override programmatically
what items the default list view template will propose for selected items.
It takes the request object for permission checking which is pretty raw but
turns out to just work: router.get_menu() returns a list of View classes of
the same Controller (thus same Model in practice), for which
view.has_perm() returns true. has_perm() is called once the view has been
hydrated with the passed request object in view.request. Your high level
code uses view.object instead of view.get_object(), because get_object()
will already be called automatically as a magic getter....
As for get_object_list horror ... hopefully it's the only class in the
whole crudlfap.views.generic that encapsulates this kind of coupling, but
at the same time the coupling in there depends on what the parent mixins
offer and that is quite tricky to get right, but at the end of the day it's
just gluing the mixins together.
Please forgive this horror story from being loaded with absolutely
non-impressive material:
https://gitpitch.com/yourlabs/crudlfap
http://crudlfap--jpic.repl.co/
http://crudlfap.rtfd.io/
Want to share more use cases with CBVs ? Reply to the list now !
Thanks for reading and have a great day ;)
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAC6Op1_bK7PJLBHOJUaUaAFRVtMNVS-J080f2SnUZmfSLzY%2B1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
