Learnlog

We can create a new admin class which will subclass ListAdminMixin & ModelAdmin

Beyond "Fat models, thin views"

Never write to a model field or call save() directly. Always use model methods and manager methods for state changing operations.This is a simple, unambiguous convention, that's easily enforceable at the point of code review.

This isn't about writing boilerplate setter properties for each field in the model, but rather about writing methods that encapsulate the point of interaction with the database layer. View code can still inspect any field on the model and perform logic based on that, but it should not modify that data directly.

Enforcing the "Never write to a model field or call save() directly." rule is particularly valuable when it comes to enforcing application data integrity between multiple model instances.

When using ModelForm you cannot use model manager .create() methods to encapsulate instance creation because the validation process requires the object to be instantiated and saved as separate steps. Calling .is_valid() instantiates the object directly, and makes it available as form.object. This object is then saved and persisted when form.save() is called.

The only place in your code where you might legitimately choose to break the contact is during test setup.

Never write to a model field or call save() directly. Always use model methods and manager methods for state changing operations.

Let’s focus on the concept of protocol in python. This not something new, you might know that calling len() in any object that contains the method __len__ will just work;

The whole concept of dependency injection in Go revolves around the idea of having interfaces as a contract. Your python object or your Go struct needs to fulfill this contract in order to be used as a parameter to a function.