Migrate to class-based views #3

New Issue

xle · 2023-08-02T14:57:46+01:00

xle commented

2023-08-02 14:57:46 +01:00

For code-efficiency, class-based views are preferred by modern Django devs. See https://docs.djangoproject.com/en/4.2/topics/class-based-views/

xle added the

Enhancement

Low Priority

labels 2023-08-02 14:57:46 +01:00

xle added the

Major Change

label 2023-08-02 15:02:32 +01:00

xle added this to the Back-end Enhancements project 2023-08-02 15:40:54 +01:00

PhilipSargent commented

2023-08-02 17:02:39 +01:00

This is a classic.
Read "Kill it with fire" - particularly the bit about "Beware of artificial consistency as proposed to "improve" technical value."

And consider much more closely the background of most of the people who have to maintain troggle.

This is a classic. Read "Kill it with fire" - particularly the bit about "Beware of artificial consistency as proposed to "improve" technical value." And consider much more closely the background of most of the people who have to maintain troggle.

xle commented

2023-08-02 20:29:24 +01:00

@PhilipSargent That's a reasonable concern - change for change's sake is not sufficiently justified. However, arbitrarily quoting blogs and books as a justification for inaction is somewhat fatuous; it is an appeal to authority rather than any kind of salient argument.

That said, worrying about future maintainers is, I concede, worth doing.

The justification for CBVs is as follows:

For common views (such as add/edit/delete operations on instances of Django models), class based views allow for code-reuse: instead of implementing a new view function for every model, you implement one generic class-based view that works for any model (using class-based forms) and then you can call it against any model/template. Obviously when you need something more specific then you can implement a more specific view, but for simple operations on simple models, a generic reusable default makes a lot of sense.

The ethos is very much along the lines of trying to produce a minimal set of "sensible defaults" for views, forms, and templates (especially using template inheritance structures) so that 90% of the work to integrate any given model into the front-end is pre-done, and you need only worry about edge-cases and context-specific issues. In short, CBVs are DRY where FBVs are WET.

As for future maintainers, class based views are not very dissimilar to functional based views in their implementation, and can be learnt very easily. Provided they are sufficiently commented and documented, this should not pose a problem - anyone who knows enough python to get their hands dirty with this project is capable of working out how a class method can replace a function. Additionally, as mentioned above, CBVs are efficient in terms of code-reuse so would serve to reduce the code-base rather than expand it, which surely makes it easier to maintain.

@PhilipSargent That's a reasonable concern - change for change's sake is not sufficiently justified. However, arbitrarily quoting blogs and books as a justification for inaction is somewhat fatuous; it is an appeal to authority rather than any kind of salient argument. That said, worrying about future maintainers is, I concede, worth doing. The justification for CBVs is as follows: For common views (such as add/edit/delete operations on instances of Django models), class based views allow for code-reuse: instead of implementing a new view function for every model, you implement one generic class-based view that works for any model (using class-based forms) and then you can call it against any model/template. Obviously when you need something more specific then you can implement a more specific view, but for simple operations on simple models, a generic reusable default makes a lot of sense. The ethos is very much along the lines of trying to produce a minimal set of "sensible defaults" for views, forms, and templates (especially using template inheritance structures) so that 90% of the work to integrate any given model into the front-end is pre-done, and you need only worry about edge-cases and context-specific issues. In short, CBVs are DRY where FBVs are WET. As for future maintainers, class based views are not very dissimilar to functional based views in their implementation, and can be learnt very easily. Provided they are sufficiently commented and documented, this should not pose a problem - anyone who knows enough python to get their hands dirty with this project is capable of working out how a class method can replace a function. Additionally, as mentioned above, CBVs are efficient in terms of code-reuse so would serve to reduce the code-base rather than expand it, which surely makes it easier to maintain.

PhilipSargent commented

2023-08-04 22:45:24 +01:00

We have very little of such commonality between our different type of objects, so this won't save any effort.
But it would make maintenance ever so much harder for most of the people we have .

Template inheritance is also used VERY SPARINGLY in troggle for exactly this reason.

We have very little of such commonality between our different type of objects, so this won't save any effort. But it would make maintenance ever so much harder for most of the people we have . Template inheritance is also used VERY SPARINGLY in troggle for exactly this reason.

xle commented

2023-08-11 11:37:11 +01:00

@PhilipSargent this does beg the question: why use a fully-featured MCV framework if you are going to intentionally subvert its features? If the explicit goal is to reinvent every wheel then why not start from the raw python webserver package and build it from the bottom up?

This seems like a very poor argument to me: to say "we use Django for this project, but we have deliberately avoided using most of the core features of Django so you can't actually refer to the Django docs but must instead rely on tribal knowledge and out-of-date pages on the handbook" seems insane. Maybe I am just missing the point.

@PhilipSargent this does beg the question: why use a fully-featured MCV framework if you are going to intentionally subvert its features? If the explicit goal is to reinvent every wheel then why not start from the raw python webserver package and build it from the bottom up? This seems like a very poor argument to me: to say "we use Django for this project, but we have deliberately avoided using most of the core features of Django so you can't actually refer to the Django docs but must instead rely on tribal knowledge and out-of-date pages on the handbook" seems insane. Maybe I am just missing the point.

PhilipSargent commented

2023-08-24 16:21:38 +01:00

Another view of class based views https://406.ch/writing/composition-over-inheritance-the-case-for-function-based-views/