So much easier handling of formsets.
Project description
django-superform
================
**Less sucking formsets.**
|build| |docs| |package| |gitter|
A ``SuperForm`` is absolutely super if you want to nest a lot of forms in each
other. Use formsets and nested forms inside the ``SuperForm``. The
``SuperForm`` will take care of its children!
.. note::
This package is still in rapid development. Some APIs might change in the
future and it's not yet feature complete. The documentation is not yet
complete either, but everything that is documented, is up to date and
should work as stated. If not, then please file a bug.
Every non-backwards compatible change and new features will be documented
in the changelog_.
.. _changelog: https://github.com/gregmuellegger/django-superform/tree/master/CHANGES.rst
Imagine you want to have a view that shows and validates a form and a formset.
Let's say you have a signup form where users can enter multiple email
addresses. Django provides formsets_ for this usecase, but handling those in a
view is usually quite troublesome. You need to validate both the form and the
formset manually and you cannot use django's generic FormView_. So here comes
**django-superform** into play.
.. _formsets: https://docs.djangoproject.com/en/1.6/topics/forms/formsets/
.. _FormView: https://docs.djangoproject.com/en/1.6/ref/class-based-views/generic-editing/#formview
Here we have an example for the usecase. Let's have a look at the
``forms.py``:
.. code-block:: python
from django import forms
from django_superform import SuperModelForm, InlineFormSetField
from myapp.models import Account, Email
class EmailForm(forms.ModelForm):
class Meta:
model = Email
fields = ('account', 'email',)
EmailFormSet = modelformset_factory(EmailForm)
class SignupForm(SuperModelForm):
username = forms.CharField()
# The model `Email` has a ForeignKey called `user` to `Account`.
emails = InlineFormSetField(formset_class=EmailFormSet)
class Meta:
model = Account
fields = ('username',)
So we assign the ``EmailFormSet`` as a field directly to the ``SignupForm``.
That's where it belongs! Ok and how do I handle this composite form in the
view? Have a look:
.. code-block:: python
def post_form(request):
if request.method == 'POST':
form = PostForm(request.POST)
if form.is_valid():
account = form.save()
return HttpResponseRedirect('/success/')
else:
form = PostForm()
return render_to_response('post_form.html', {
'form',
}, context_instance=RequestContext(request))
No, we don't do anything different as we would do without having the
``FormSet`` on the ``SignupForm``. That way you are free to implement all the
logic in the form it self where it belongs and use generic views like
``CreateView`` you would use them with simple forms. Want an example for this?
.. code-block:: python
from django.views.generic import CreateView
from myapp.models import Account
from myapp.forms import SignupForm
class SignupView(CreateView):
model = Account
form_class = SignupForm
urlpatterns = patterns('',
url('^signup/$', SignupView.as_view()),
)
And it just works.
Documentation
-------------
Full documentation is available on Read The Docs: https://django-superform.readthedocs.org/
----
Developed by Gregor Müllegger in cooperation with Team23_.
.. _Team23: http://www.team23.de/
.. |build| image:: https://travis-ci.org/gregmuellegger/django-superform.svg?branch=master
:alt: Build Status
:scale: 100%
:target: https://travis-ci.org/gregmuellegger/django-superform
.. |docs| image:: https://readthedocs.org/projects/django-superform/badge/?version=latest
:alt: Documentation Status
:scale: 100%
:target: https://django-superform.readthedocs.org/
.. |package| image:: https://badge.fury.io/py/django-superform.svg
:alt: Package Version
:scale: 100%
:target: http://badge.fury.io/py/django-superform
.. |gitter| image:: https://badges.gitter.im/JoinChat.svg
:alt: Gitter Chat, discuss django-superform with others
:scale: 100%
:target: https://gitter.im/gregmuellegger/django-superform
Changelog
=========
0.3.0
-----
* `#11`_: Fix ``CompositeBoundField`` to allow direct access to nested form
fields via ``form['nested_form']['field']``.
* Support for Django's Media handling in nested forms. See `#3`_ and `#5`_.
* Do not populate errorlist representations without any errors of nested
formsets into the errors of the super form. See `#5`_ for details.
.. _#3: https://github.com/gregmuellegger/django-superform/issues/3
.. _#5: https://github.com/gregmuellegger/django-superform/pull/5
.. _#11: https://github.com/gregmuellegger/django-superform/issues/11
0.2.0
-----
* Django 1.8 support.
* Initial values given to the ``__init__`` method of the super-form will get
passed through to the nested forms.
* The ``empty_permitted`` argument for modelforms used in a ``ModelFormField``
is set depending on the ``required`` attribute given to the field.
0.1.0
-----
* Initial release with proof of concept.
================
**Less sucking formsets.**
|build| |docs| |package| |gitter|
A ``SuperForm`` is absolutely super if you want to nest a lot of forms in each
other. Use formsets and nested forms inside the ``SuperForm``. The
``SuperForm`` will take care of its children!
.. note::
This package is still in rapid development. Some APIs might change in the
future and it's not yet feature complete. The documentation is not yet
complete either, but everything that is documented, is up to date and
should work as stated. If not, then please file a bug.
Every non-backwards compatible change and new features will be documented
in the changelog_.
.. _changelog: https://github.com/gregmuellegger/django-superform/tree/master/CHANGES.rst
Imagine you want to have a view that shows and validates a form and a formset.
Let's say you have a signup form where users can enter multiple email
addresses. Django provides formsets_ for this usecase, but handling those in a
view is usually quite troublesome. You need to validate both the form and the
formset manually and you cannot use django's generic FormView_. So here comes
**django-superform** into play.
.. _formsets: https://docs.djangoproject.com/en/1.6/topics/forms/formsets/
.. _FormView: https://docs.djangoproject.com/en/1.6/ref/class-based-views/generic-editing/#formview
Here we have an example for the usecase. Let's have a look at the
``forms.py``:
.. code-block:: python
from django import forms
from django_superform import SuperModelForm, InlineFormSetField
from myapp.models import Account, Email
class EmailForm(forms.ModelForm):
class Meta:
model = Email
fields = ('account', 'email',)
EmailFormSet = modelformset_factory(EmailForm)
class SignupForm(SuperModelForm):
username = forms.CharField()
# The model `Email` has a ForeignKey called `user` to `Account`.
emails = InlineFormSetField(formset_class=EmailFormSet)
class Meta:
model = Account
fields = ('username',)
So we assign the ``EmailFormSet`` as a field directly to the ``SignupForm``.
That's where it belongs! Ok and how do I handle this composite form in the
view? Have a look:
.. code-block:: python
def post_form(request):
if request.method == 'POST':
form = PostForm(request.POST)
if form.is_valid():
account = form.save()
return HttpResponseRedirect('/success/')
else:
form = PostForm()
return render_to_response('post_form.html', {
'form',
}, context_instance=RequestContext(request))
No, we don't do anything different as we would do without having the
``FormSet`` on the ``SignupForm``. That way you are free to implement all the
logic in the form it self where it belongs and use generic views like
``CreateView`` you would use them with simple forms. Want an example for this?
.. code-block:: python
from django.views.generic import CreateView
from myapp.models import Account
from myapp.forms import SignupForm
class SignupView(CreateView):
model = Account
form_class = SignupForm
urlpatterns = patterns('',
url('^signup/$', SignupView.as_view()),
)
And it just works.
Documentation
-------------
Full documentation is available on Read The Docs: https://django-superform.readthedocs.org/
----
Developed by Gregor Müllegger in cooperation with Team23_.
.. _Team23: http://www.team23.de/
.. |build| image:: https://travis-ci.org/gregmuellegger/django-superform.svg?branch=master
:alt: Build Status
:scale: 100%
:target: https://travis-ci.org/gregmuellegger/django-superform
.. |docs| image:: https://readthedocs.org/projects/django-superform/badge/?version=latest
:alt: Documentation Status
:scale: 100%
:target: https://django-superform.readthedocs.org/
.. |package| image:: https://badge.fury.io/py/django-superform.svg
:alt: Package Version
:scale: 100%
:target: http://badge.fury.io/py/django-superform
.. |gitter| image:: https://badges.gitter.im/JoinChat.svg
:alt: Gitter Chat, discuss django-superform with others
:scale: 100%
:target: https://gitter.im/gregmuellegger/django-superform
Changelog
=========
0.3.0
-----
* `#11`_: Fix ``CompositeBoundField`` to allow direct access to nested form
fields via ``form['nested_form']['field']``.
* Support for Django's Media handling in nested forms. See `#3`_ and `#5`_.
* Do not populate errorlist representations without any errors of nested
formsets into the errors of the super form. See `#5`_ for details.
.. _#3: https://github.com/gregmuellegger/django-superform/issues/3
.. _#5: https://github.com/gregmuellegger/django-superform/pull/5
.. _#11: https://github.com/gregmuellegger/django-superform/issues/11
0.2.0
-----
* Django 1.8 support.
* Initial values given to the ``__init__`` method of the super-form will get
passed through to the nested forms.
* The ``empty_permitted`` argument for modelforms used in a ``ModelFormField``
is set depending on the ``required`` attribute given to the field.
0.1.0
-----
* Initial release with proof of concept.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
django-superform-0.3.0.tar.gz
(24.0 kB
view details)
File details
Details for the file django-superform-0.3.0.tar.gz
.
File metadata
- Download URL: django-superform-0.3.0.tar.gz
- Upload date:
- Size: 24.0 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | c9dd821ec56fa9d4cfd464482ed3b2a19a65f4776993bf2985ad7a3891e643ca |
|
MD5 | 20d0d60673e18d407dfcaa35c396c04e |
|
BLAKE2b-256 | 6d309e55ac811fc841dde275085069dddb76bd0a99b7db1507328635905c5c55 |