A set of high-level abstractions for Django forms

Overview

django-formtools

Jazzband PyPI version Supported Python versions GitHub Actions Test Coverage

Django's "formtools" is a set of high-level abstractions for Django forms. Currently for form previews and multi-step forms.

This code used to live in Django proper -- in django.contrib.formtools -- but was separated into a standalone package in Django 1.8 to keep the framework's core clean.

For a full list of available formtools, see https://django-formtools.readthedocs.io/

django-formtools can also be found on and installed from the Python Package Index: https://pypi.python.org/pypi/django-formtools

To get more help:

Contributing to django-formtools

See CONTRIBUTING.rst for information about contributing patches to django-formtools.

Running tests is as simple as installing Tox and running it in the root Git clone directory:

$ git clone https://github.com/jazzband/django-formtools
[..]
$ cd django-formtools
$ tox
[..]
  congratulations :)

The previous command will run the tests in different combinations of Python (if available) and Django versions. To see the full list of combinations use the -l option:

$ tox -l
...
py38-django-AB
py38-django-master

You can run each environment with the -e option:

$ tox -e py38-django-AB  # runs the tests only on Python 3.5 and Django A.B.x

Optionally you can also specify a country whose tests you want to run:

$ COUNTRY=us tox

And combine both options:

$ COUNTRY=us tox -e py38-django-AB
Comments
  • Implement Jazzband guidelines for django-formtools

    Implement Jazzband guidelines for django-formtools

    This issue tracks the implementation of the Jazzband guidelines for the project django-formtools

    It was initiated by @felixxm who was automatically assigned in addition to the Jazzband roadies.

    See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

    Feel free to ping a Jazzband roadie if you have any question.

    TODOs

    • [x] Fix all links in the docs (and README file etc) from old to new repo
    • [x] Add the Jazzband badge to the README file
    • [x] Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
    • [x] Check if continuous testing works (e.g. Travis-CI, CircleCI, AppVeyor, etc)
    • [x] Check if test coverage services work (e.g. Coveralls, Codecov, etc)
    • [x] Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/django-formtools/collaboration/)
    • [x] Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-formtools/users/)
    • [x] Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-formtools/integrations/)
    • [x] Fix project URL in GitHub project description
    • [x] Review project if other services are used and port them to Jazzband
    • [x] Decide who is project lead for the project (if at all)
    • [x] Set up CI for Jazzband project releases if needed and open ticket if yes

    Project details

    Description A set of high-level abstractions for Django forms
    Homepage https://django-formtools.readthedocs.io/
    Stargazers 336
    Open issues 55
    Forks 84
    Default branch master
    Is a fork False
    Has Wiki False
    Has Pages False
    opened by jazzband-bot 11
  • Maybe time for a release?

    Maybe time for a release?

    Django 3.0 will soon be out there, and the latest release of django-formtools cannot work on Django 3 because Python 2 support was dropped (no django.utils.six anymore.). I can see that Python 2 (and therefore usage of six) is already dropped from master here. But until there is a release, it's not possible to use this on Django 3. Please do some release and publish it on pypi so that django-formtools can be used with Django 3.

    opened by fallen 9
  • Use get_form_list() instead of form_list

    Use get_form_list() instead of form_list

    I have a use case where I inject extra steps (dynamically, in some cases), and this was the only change I needed to make.

    Is there a reason that this line is not already using self.get_form_list()?

    needs tests 
    opened by schinckel 9
  • Django 3.0 compatibility

    Django 3.0 compatibility

    Django will remove the vendored django.utils.six in the upcoming 3.0 release. six is in use in django-formtools for normalization of string types and iteration.

    Since I see that the next version of django-formtools will drop support for Django versions 1.10 and below, and will add support for 2.1, the smoothest experience for everybody concerned would probably be to depend on six directly for a bit?

    opened by rixx 8
  • Random test failure: TestCookieStorage.test_reset_cookie

    Random test failure: TestCookieStorage.test_reset_cookie

    Originally reported in #23792. Should we use the freeze_time() contextmanager proposed there? If so, it seems we'll have to drop compatibility with Django 1.7.

    opened by timgraham 8
  • [BUG]: Release 2.2 breaking Python 2.7

    [BUG]: Release 2.2 breaking Python 2.7

    The release from 2h ago is breaking python 2.7 (in my case tests). It is clear that you wanted to deprecate the support for python 2.7 . But for pip to not allow the installation on python 2.7, https://github.com/jazzband/django-formtools/blob/bffb403ceaca78563548dd01d1103373f12c80ac/setup.py#L135 needs to be: "Programming Language :: Python :: 3 :: Only",

    "Programming Language :: Python referes to universal python (2 and 3), which caused PyPi to allow the installation of 'django-formtools==2.2' on python 2.7.

    Same as https://github.com/jazzband/django-formtools/blob/bffb403ceaca78563548dd01d1103373f12c80ac/setup.cfg#L17 which also should be deleted to prevent mixups, also the meta information in setup.py are more important for PyPi's 'match making' I think.

    opened by s-weigand 7
  • Fix infinite recursion error #220

    Fix infinite recursion error #220

    This removes the undocumented get_form_list since the process of repeatedly and dynamically generating an OrderedDict of steps/forms pairs leads to infinite recursion. This is replaced with a new method process_condition_dict which directly modifies form_list in place, in a single step executed prior to dispatching to get or post. This eliminates infinite recursion since the form_list is calculated exactly once prior to any other attempts to access and process forms.

    Removed test_form_condition_unstable since this is an odd test (why would a condition_dict return value suddenly change in the middle of a request/response cycle?) that was attempting to deal with invalid steps (invalid steps are better handled through actual validation, see #224).

    For users who need to dynamically add forms, this can be handled by overriding process_condition_dict.

    opened by jsma 6
  • ManagementForm data is missing or has been tampered with

    ManagementForm data is missing or has been tampered with

    I have been struggling with this for a long time. Will you please help me on this. This is not letting me sleep for a long time. Please help. My view `def daily_report_create_view(request): district = 'Natore' if request.method == 'GET': form = DAILY_REPORT_FORM(request.POST) g1_form = G1_FORM() g2_form = G2_FORM() g3_form = G3_FORM() g4_form = G4_FORM() g5_form = G5_FORM() g6_form = G6_FORM() g7_form = G7_FORM() g8_formset = G8_FormSet(request.POST)

    elif   request.method == 'POST':
        form = DAILY_REPORT_FORM(request.POST)
        # familyMemberFormeset = FamilyMemberFormSet(request.POST)
        g1_form = G1_FORM(request.POST)
        g2_form = G2_FORM(request.POST)
        g3_form = G3_FORM(request.POST)
        g4_form = G4_FORM(request.POST)
        g5_form = G5_FORM(request.POST)
        g6_form = G6_FORM(request.POST)
        g7_form = G7_FORM(request.POST)
        g8_formset = G8_FormSet(request.POST)
    
        if form.is_valid() and g1_form.is_valid() and g2_form.is_valid() and g3_form.is_valid() and g4_form.is_valid()\
                and g5_form.is_valid() and g6_form.is_valid() and g7_form.is_valid() and g8_formset.is_valid():
    
            print(g8_formset.cleaned_data)
    
    
    context = {
        'form': form,
        'g1_form': g1_form,
        'g2_form': g2_form,
        'g3_form': g3_form,
        'g4_form': g4_form,
        'g5_form': g5_form,
        'g6_form': g6_form,
        'g7_form': g7_form,
        'g8_formset': g8_formset
    }
    
    return render(request, 'morningReport/report_create.html', context)`
    

    My template: ` {{ g8_formset.management_form }} {% for link_form in g8_formset %}

    opened by Mushahid2521 6
  • FormWizard does not support internationalization of named wizard steps

    FormWizard does not support internationalization of named wizard steps

    Hi all, I'm trying to translate my django app, and all aspects work except for the formtools wizard, specifically the strings assigned to my multistep forms. In Urls.py I have:

    named_formwizard_forms = ( (('Your Details'), FormStepOne), (('Residence Preference'), FormStepTwo), (('Immigration & Schooling'), FormStepThree), (('Mobility Expenses'), FormStepFour), (_('Living Expenses'), FormStepFive), ) urlpatterns = [ path(_('form/'), FormWizardView.as_view(named_formwizard_forms),name="form"), ] When I makemessages, the strings show up in my django.po, and while i have translated them to french, they either do not compile or there is some format I am missing in the template. Please advise.

    Thanks

    opened by lulumuts 5
  • PyPI release for django 1.10 compatibility

    PyPI release for django 1.10 compatibility

    Hello,

    I would like about new PyPI releases of django-formtools. Django 1.10 was released. 46b6839fb0063fa10ffb896ce80f7155ca7a9f6e contains fix for django 1.10 compatibility (below are stacktrace without that). 54f1ccca01e1a2d2062ad76af9c559723edd435c proves that django-formtools is django 1.10 compatibile. I think is good to release django-1.10-compatible version of django-formtools.

    $ python manage.py test feder --keepdb
    Using existing test database for alias 'default'...
    ...................E........................................................................................
    ======================================================================
    ERROR: test_permitted_user (feder.letters.tests.test_view.ReplyPermissionTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/adas/Devel/feder/feder/letters/tests/test_view.py", line 85, in test_permitted_user
        response = self.client.get(self._get_url())
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 529, in get
        **extra)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 333, in get
        return self.generic('GET', path, secure=secure, **r)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 409, in generic
        return self.request(**r)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 494, in request
        six.reraise(*exc_info)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/exception.py", line 39, in inner
        response = get_response(request)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
        response = self._get_response(request)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 187, in _get_response
        response = self.process_exception_by_middleware(e, request)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 185, in _get_response
        response = wrapped_callback(request, *callback_args, **callback_kwargs)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/utils/decorators.py", line 185, in inner
        return func(*args, **kwargs)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view
        return view_func(request, *args, **kwargs)
      File "/home/adas/Devel/feder/feder/letters/views.py", line 94, in __call__
        return method(request)
      File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/formtools/preview.py", line 58, in preview_get
        context_instance=RequestContext(request))
    TypeError: render_to_response() got an unexpected keyword argument 'context_instance'
    
    ----------------------------------------------------------------------
    
    opened by ad-m 5
  • Prepare release of v2.3

    Prepare release of v2.3

    I looked over all the changes since the last tag and the changelog seemed correct, so I'm just optimistically placing the date in the changelog to today.

    opened by rtpg 4
  • Improve testing

    Improve testing

    The latest release broke a documented feature.

    Regardless of how this situation will be solved, I propose to improve automated testing. Here are some of my suggested changes.

    It includes a currently @unittest.skip() marked test (FormTests.test_form_condition_callable) which leads to a RecursionError due to using get_cleaned_data_for_step in a condition_dict callback.

    opened by fdemmer 2
  • Update `ManagementForm` to validate `current_step`

    Update `ManagementForm` to validate `current_step`

    Previously, bots could and would stuff this form value with all kinds of nonsense, triggering a server error (and subsequent alert emails). Supersedes #47 and should fix #38

    opened by jsma 0
  • Fixing #220 (by reverting the breaking change)

    Fixing #220 (by reverting the breaking change)

    Please see #220, this is causing a lot of problems as a breaking change was accidentally introduced in 2.4.

    It might be that there is a "better" fix in #221 or via another solution, but I think the priority should be to release 2.4.1 with this PR in and the original functionality fixed.

    This would buy time to find a better solution that allows for the request of #168 to be implemented without causing the problems that the original change caused.

    Thank you for this fantastic package.

    opened by violuke 7
  • Possible solution for #220

    Possible solution for #220

    This shows a possible approach we can use to fix the infinite recursion that can be triggered by referring to step data from condition_dict callables.

    opened by schinckel 2
  • Infinite Recursion possible in 2.4

    Infinite Recursion possible in 2.4

    We have a condition_dict containing the following function:

    def need_further_steps(wizard):
        data = wizard.get_cleaned_data_for_step("0") or {}
        if data.get("no_invoices_needed", False):
            return False
        return True
    

    The call to WizardView.get_cleaned_data_for_step then calls WizardView.get_form, which used to reference self.form_list, but the following commit changes this to self.get_form_list(), which then calls the user-supplied condition_dict functions, which then calls our need_further_steps function above, which calls WizardView.get_cleaned_data_for_step, and so on ad infinitum. https://github.com/jazzband/django-formtools/commit/533a83053deab2adeb72de079e813aae78b03c1a

    Perhaps our custom condition function is bad, but it doesn't seem too unreasonable?

    opened by dave-v 38
Owner
Jazzband
We are all part of this
Jazzband
The best way to have DRY Django forms. The app provides a tag and filter that lets you quickly render forms in a div format while providing an enormous amount of capability to configure and control the rendered HTML.

django-crispy-forms The best way to have Django DRY forms. Build programmatic reusable layouts out of components, having full control of the rendered

null 4.6k Dec 31, 2022
A flexible forms validation and rendering library for Python.

WTForms WTForms is a flexible forms validation and rendering library for Python web development. It can work with whatever web framework and template

WTForms 1.4k Dec 31, 2022
A CBV to handle multiple forms in one view

django-shapeshifter A common problem in Django is how to have a view, especially a class-based view that can display and process multiple forms at onc

Kenneth Love 167 Nov 26, 2022
Tweak the form field rendering in templates, not in python-level form definitions. CSS classes and HTML attributes can be altered.

django-widget-tweaks Tweak the form field rendering in templates, not in python-level form definitions. Altering CSS classes and HTML attributes is su

Jazzband 1.8k Jan 6, 2023
Bootstrap 3 integration with Django.

django-bootstrap3 Bootstrap 3 integration for Django. Goal The goal of this project is to seamlessly blend Django and Bootstrap 3. Want to use Bootstr

Zostera B.V. 2.3k Dec 24, 2022
Bootstrap 4 integration with Django.

django-bootstrap 4 Bootstrap 4 integration for Django. Goal The goal of this project is to seamlessly blend Django and Bootstrap 4. Requirements Pytho

Zostera B.V. 979 Dec 26, 2022
A platform independent django form serializer

django-remote-forms A package that allows you to serialize django forms, including fields and widgets into Python dictionary for easy conversion into

WiserTogether, Inc. 219 Sep 20, 2022
A fresh approach to autocomplete implementations, specially for Django. Status: v3 stable, 2.x.x stable, 1.x.x deprecated. Please DO regularely ping us with your link at #yourlabs IRC channel

Features Python 2.7, 3.4, Django 2.0+ support (Django 1.11 (LTS), is supported until django-autocomplete-light-3.2.10), Django (multiple) choice suppo

YourLabs 1.7k Jan 1, 2023
A set of high-level abstractions for Django forms

django-formtools Django's "formtools" is a set of high-level abstractions for Django forms. Currently for form previews and multi-step forms. This cod

Jazzband 621 Dec 30, 2022
The best way to have DRY Django forms. The app provides a tag and filter that lets you quickly render forms in a div format while providing an enormous amount of capability to configure and control the rendered HTML.

django-crispy-forms The best way to have Django DRY forms. Build programmatic reusable layouts out of components, having full control of the rendered

null 4.6k Jan 5, 2023
The best way to have DRY Django forms. The app provides a tag and filter that lets you quickly render forms in a div format while providing an enormous amount of capability to configure and control the rendered HTML.

django-crispy-forms The best way to have Django DRY forms. Build programmatic reusable layouts out of components, having full control of the rendered

null 4.6k Dec 31, 2022
The best way to have DRY Django forms. The app provides a tag and filter that lets you quickly render forms in a div format while providing an enormous amount of capability to configure and control the rendered HTML.

django-crispy-forms The best way to have Django DRY forms. Build programmatic reusable layouts out of components, having full control of the rendered

null 4.6k Jan 7, 2023
Creating low-level foundations and abstractions for asynchronous programming in Python.

DIY Async I/O Creating low-level foundations and abstractions for asynchronous programming in Python (i.e., implementing concurrency without using thr

Doc Jones 4 Dec 11, 2021
django-quill-editor makes Quill.js easy to use on Django Forms and admin sites

django-quill-editor django-quill-editor makes Quill.js easy to use on Django Forms and admin sites No configuration required for static files! The ent

lhy 139 Dec 5, 2022
Automatically download the cwru data set, and then divide it into training data set and test data set

Automatically download the cwru data set, and then divide it into training data set and test data set.自动下载cwru数据集,然后分训练数据集和测试数据集

null 6 Jun 27, 2022
Voxel Set Transformer: A Set-to-Set Approach to 3D Object Detection from Point Clouds (CVPR 2022)

Voxel Set Transformer: A Set-to-Set Approach to 3D Object Detection from Point Clouds (CVPR2022)[paper] Authors: Chenhang He, Ruihuang Li, Shuai Li, L

Billy HE 141 Dec 30, 2022
Data loaders and abstractions for text and NLP

torchtext This repository consists of: torchtext.data: Generic data loaders, abstractions, and iterators for text (including vocabulary and word vecto

null 3.2k Dec 30, 2022
Data loaders and abstractions for text and NLP

torchtext This repository consists of: torchtext.data: Generic data loaders, abstractions, and iterators for text (including vocabulary and word vecto

null 2.6k Feb 18, 2021
Data loaders and abstractions for text and NLP

torchtext This repository consists of: torchtext.datasets: The raw text iterators for common NLP datasets torchtext.data: Some basic NLP building bloc

null 3.2k Jan 8, 2023