difficult to use it with other forms

[slepa]

I can't guess, how i can merge PostalAddressForm with MyProfileForm.

I think i have a usual task - add address field to my ProfileModel.

my profile form is
class ProfileForm(ModelForm):
class Meta(object):
model = Profile

so inheritance can't work.

I'd like to combine them:

{% csrf_token %} {{ address_form.as_p }} {{ profile_form.as_p }} {% monitor_country_change %} <script type="text/javascript"> $('form').monitor_country_change('#id_country'); </script>

    <input type="submit" value="Submit" />

but monitor_country_change will overwrite the entire form.

[codingjoe]

True, Widgets would have been better, or even a field using that widgets and joins all input.

But I guess this repo is dead. I might fork it an continue working on it, but I would need @mthornhill to change the license. I prefer MIT over BSD.

[mthornhill]

Hi CodingJoe,
Widgets sounds like a good idea, if you can implement this, I would be happy to accept a pull request, I can change the license to MIT in the meantime.
Thanks
Michael

[codingjoe]

Ok, lets talks about this a little more, shall we?

There are different approaches to solve this issue.

First would be the usage of a single models.CharField and a Widget that splits and joins the single forms.Field.
I don't really like this idea. I know it has been done this way before in many cases but it violates the ACID paradigm and 1NF for not being atomic.

Second would be to have an abstract postal super class that includes all required fields and you can just add fields. That would allow each entity to a distinct postal address.
That's nice but only meets 1NF and doesn't allow [1:N] but [1:1] entity address relations.
What about objects that have more than one address? Like a customer with a billing and shipping address?

I would go with a different approach, that doesn't even require too much change to the existing code.

I would create a base model for addresses that the address form extends. Than I would create a field that would inherit models.ForeignKey or even models.ManyToManyField and at could be attached to a Widget that would handle saving address to a different db-table and setting the foreign key or ManyToMay.
That way users could just drop a PostalField into their code and the rest would be done in the background.
This solution would be 2NF conform and allow [n:n] realtions between addresses and entities.
On the other hand this solution would require users to always include names into the address, but we could maybe pass that to the widget.

What do you think? I'd be starting working on that tomorrow.

[codingjoe]

codingjoe/django-postal@7f67de5

I wrote a base for future implementation right here. It doesn't really cover all the functionality but it's a start.