-
Notifications
You must be signed in to change notification settings - Fork 14
Why we have to bind the process with model through mixin?
Emil edited this page Jan 14, 2020
·
4 revisions
If you have a question of why we have designed the binding mechanism through a mixin, please read this answer. Also, feel free to suggest a better solution if you have one.
Here is an example:
class Invoice(ProcessManager.bind_state_fields(status=InvoiceProcess), models.Model):
status = models.CharField(choices=InvoiceProcess.states, default='draft', max_length=16, blank=True)However, there are the following features we try to support at the same time:
- Support multiple states and processes within one model
- Protect state fields being overwritten during the execution of the
savemethod - There should be only one place/mechanism to bind the state field and
Process - It seems to be a good idea to have a
StateFieldwhich binds theProcess. However, it will require a mixin to protect the state field being overwritten which ruins the magic and rises a number of bugs if forgotten. - Another good idea is to define process the same way, we define objects with Manager, e.g.
process = FulfilmentProcess(state_field=‘state’), but in that case, we have to define Process either as a descriptor, or somehow else, and rewrite the Process class, it also affects the testing process of Process classes, as well as requires an extra mixin to keep the state fields read only.