attributes_for?

[proofit404]

Is there any possibility to do something like this

from model_mommy import mommy
attrs = mommy.attributes_for('Person')
self.client.post(reverse('app:update-person'), attrs)

Also more awesome usage for me looks like this

from app.forms import PersonForm
from model_mommy import mommy
attrs = mommy.attributes_for(PersonForm)
self.client.post(reverse('app:update-person'), attrs)

Second example allows to handle separated forms with different field sets.

[berinhard]

I'm a :+1: for this feature, but I don't agree with the Form handling because it's outside of model_mommy's scope. I think that you've suggested this just to handle with new required or non-required fields for a ModelForm. To handle this, I'd like to add this suggestion to the API:

attrs = mommy.attributess_for('Person', name="Guido", _fill_optional=["address"])
# this returns {"name": "Guido", "address": "axsljrrawo3aoaisda", "age": 42}

[proofit404]

@berinhard I suggest form feature because it's really convenient to make attributes for some form. If you change form you doesn't need to change every single test which use this form. You doesn't need to repeat this attributes over and over again in your tests.

[berinhard]

@proofit404 I understood why you suggested it and how it would make it more convenient to generate attributes. But I think that handling with forms could lead us to other problems that are outside the scope of model mommy. Let's think about this example:

class Person(models.Model):
    name = models.CharField(max_length=30)
    age = models.IntegerField()

##### on forms.py

class PersonForm(forms.ModelForm):
    email_notification = forms.EmailField()

    class Meta:
        model = Person

In the example above, we have an extra and required field for the form that it's not in the Person model too. This lead us to a scenario that, today, model mommy does not know how to handle. This is the kind of trouble of API design that I'd like to avoid... What do you think about it?

Going further, what do you think about we, as a first step, implements the API that I've suggested working just for models and we keep on discussing about how could we handle the forms?

[proofit404]

Interesting example indeed. In my opinion we must handle field specified both in form and in its model. This solution will lead to support forms fields and model fields recognition. This is really complex task. Also user may want to write its own recipe for his form. Maybe this is goal for another package like "form mommy". But I'm not quiet sure since it's a lot of duplications in this functionality.

[proofit404]

Implement model part of this functionality is a good point to start I think.

[berinhard]

@proofit404 maybe we could think this "form mommy" as a plugin or extensions for model mommy. Nose and py.test (i'm not so sure about the second one) does that using setuptools entry points.

[proofit404]

Plug-in based system looks nice. But does it's really necessary? I mean how many plug-ins we can made with make, prepare and attributes_for api support. The only use case I can imagine is supporting different relation mappers like sqlalchemy or different form processing libraries like wtforms.

I agree with setuptools entry points because it is most common way to do this stuff.

[vandersonmota]

Closing due inactivity