pas.forms.party
===============

.. py:module:: pas.forms.party


Classes
-------

.. autoapisummary::

   pas.forms.party.PartyForm


Module Contents
---------------

.. py:class:: PartyForm(formdata: webob.multidict.MultiDict[str, Any] | None = None, obj: object | None = None, prefix: str = '', data: dict[str, Any] | None = None, meta: dict[str, Any] | None = None, *, extra_filters: collections.abc.Mapping[str, collections.abc.Sequence[Any]] | None = None, **kwargs: Any)

   Bases: :py:obj:`onegov.form.Form`


   Extends wtforms.Form with useful methods and integrations needed in
   OneGov applications.

   **Fieldsets**

   This form supports fieldsets (which WTForms doesn't recognize). To put
   fields into a fieldset, add a fieldset attribute to the field during
   class definition::

       class MyForm(Form):
           first_name = StringField('First Name', fieldset='Name')
           last_name = StringField('Last Name', fieldset='Name')
           comment = StringField('Comment')

   A form created like this will have two fieldsets, one visible fieldset
   with the legend set to 'Name' and one invisible fieldset containing
   'comment'.

   Fieldsets with the same name are *not* automatically grouped together.
   Instead, fields are taken in the order they are defined and put into the
   same fieldset, if the previous fieldset has the same name.

   That is to say, in this example, we get three fieldsets::

       class MyForm(Form):
           a = StringField('A', fieldset='1')
           b = StringField('B', fieldset='2')
           c = StringField('C', fieldset='1')

   The first fieldset has the label '1' and it contains 'a'. The second
   fieldset has the label '2' and it contains 'b'. The third fieldset has
   the label '3' and it contains 'c'.

   This ensures that all fields are in either a visible or an invisible
   fieldset (see :meth:`Fieldset.is_visible`).

   **Dependencies**

   This form also supports dependencies. So field b may depend on field a, if
   field a has a certain value, field b is shown on the form (with some
   javascript) and its validators are actually executed. If field a does
   not have the required value, field b is hidden with javascript and its
   validators are not executed.

   The validators which are skipped are only the validators passed with the
   field, the validators on the field itself are still invoked (we can't
   skip them). However, only if the optional field is not empty. That is we
   prevent invalid values no matter what, but we allow for empty values if
   the dependent field does not have the required value.

   This sounds a lot more complicated than it is::

       class MyForm(Form):

           option = RadioField('Option', choices=[
               ('yes', 'Yes'),
               ('no', 'No'),
           ])
           only_if_no = StringField(
               label='Only Shown When No',
               validators=[InputRequired()],
               depends_on=('option', 'no')
           )

   **Pricing**

   Pricing is a way to attach prices to certain form fields. A total price
   is calcualted depending on the selections the user makes::

       class MyForm(Form):

           ticket_insurance = RadioField('Option', choices=[
               ('yes', 'Yes'),
               ('no', 'No')
           ], pricing={
               'yes': (10.0, 'CHF')
           })

           stamps = IntegerRangeField(
           'No. Stamps',
           range=range(0, 30),
           pricing={range(0, 30): (1.00, 'CHF')}
       )

           delivery = RadioField('Delivery', choices=[
               ('pick_up', 'Pick up'),
               ('post', 'Post')
           ], pricing={
               'post': (5.0, 'CHF', True)
           })

           discount_code = StringField('Discount Code', pricing={
               'CAMPAIGN2017': (-5.0, 'CHF')
           })

   Note that the pricing has no implicit meaning. This is simply a way to
   attach prices and to get the total through the ``prices()`` and ``total()``
   calls. What you do with these prices is up to you.

   Pricing can optionally take a third boolean value indicating that this
   option will make credit card payments mandatory.



   .. py:attribute:: name


   .. py:attribute:: start


   .. py:attribute:: end


   .. py:attribute:: portrait


   .. py:attribute:: description