DRY defining form?!?

[jedie]

I've just noticed this project now ;)

The example in the docs (and the README) defines a Service class with form fields and it seems that i have to create a separate form class, isn't it?

So the form fields are defined two times. It's against the DRY concept...

I can see the need for it. For example, if a view form creates several model instances at the same time.

However, this is too costly for simple cases.
Am I missing something?

[c17r]

Since the Service class is derived from Form, you could use it for both purposes. The ServiceView for CBVs will use service_class for both if form_class isn't defined.

But the "unique selling point" of Django Service Objects is that each Service Object is a self-contained business rule abstraction. The inputs into the business rule may not match the inputs of the form. Plus, Service Objects let us validate the parameters to the business rule.

Examples, particularly quick ones in READMEs, are a balancing act between simple enough so people get the gist of the library quickly and being thorough.

[mixxorz]

Also, if you want to DRY up your forms, you can group your fields into mixins like so:

from django import forms
from django.forms.forms import DeclarativeFieldsMetaclass

class UserProfileMixin(object, metaclass=DeclarativeFieldsMetaClass):
    username = forms.CharField()
    name = forms.CharField()
    email = forms.EmailField()

    def clean_username(self):
        # ... some shared cleaning method

Then to use as a form/service

class RegisterUserService(UserProfileMixin, Service):
    pass


class UserProfileForm(UserProfileMixin, forms.Form):
    pass