:py:mod:`oioioi.base.fields` ============================ .. py:module:: oioioi.base.fields Module Contents --------------- Classes ~~~~~~~ .. autoapisummary:: oioioi.base.fields.DottedNameField oioioi.base.fields.EnumRegistry oioioi.base.fields.EnumField oioioi.base.fields.PhoneNumberField oioioi.base.fields.PostalCodeField .. py:class:: DottedNameField(superclass, *args, **kwargs) Bases: :py:obj:`django.db.models.CharField` A ``CharField`` designed to store dotted names of Python classes. The mandatory argument ``superclass`` should be the class, which subclasses can be stored in such fields. Possible choices are automatically provided to Django, if the superclass has an attribute ``subclasses`` listing possible subclasses. :cls:`oioioi.base.utils.RegisteredSubclassesBase` may be used to automatically build such an attribute. Before looking up subclasses, modules with names specified in the ``modules_with_subclasses`` class attribute of ``superclass`` are loaded from all applications registered with Django. Subclasses may define ``description``s, which will be shown to the users in auto-generated forms instead of dotted names. .. py:attribute:: description .. py:attribute:: choices .. py:method:: get_choices(include_blank=True, blank_choice=BLANK_CHOICE_DASH, limit_choices_to=None) Copied from Field and replaced self.choices with generate_choices to avoid circular dependency. .. py:method:: _get_choices() .. py:method:: validate(value, model_instance) Validate value and raise ValidationError if necessary. Subclasses should override this to provide validation logic. .. py:method:: _get_superclass() .. py:method:: _generate_choices() .. py:method:: to_python(value) Convert the input value into the expected Python data type, raising django.core.exceptions.ValidationError if the data can't be converted. Return the converted value. Subclasses should override this. .. py:method:: deconstruct() Return enough information to recreate the field as a 4-tuple: * The name of the field on the model, if contribute_to_class() has been run. * The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better. * A list of positional arguments. * A dict of keyword arguments. Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types): * None, bool, str, int, float, complex, set, frozenset, list, tuple, dict * UUID * datetime.datetime (naive), datetime.date * top-level classes, top-level functions - will be referenced by their full import path * Storage instances - these have their own deconstruct() method This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined. There's no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values. .. py:class:: EnumRegistry(max_length=64, entries=None) Bases: :py:obj:`object` .. py:method:: __iter__() .. py:method:: __getitem__(key) .. py:method:: register(value, description) .. py:method:: get(value, fallback) Return description for a given value, or fallback if value not in registry .. py:class:: EnumField(registry=None, *args, **kwargs) Bases: :py:obj:`django.db.models.CharField` A ``CharField`` designed to store a value from an extensible set. The set of possible values is stored in an :cls:`EnumRegistry`, which must be passed to the constructor. Other apps may then extend the set of available choices by calling :meth:`EnumRegistry.register`. The list of choices is populated the first time it is needed, therefore other application should probably register their values early during initialization, preferably in their ``models.py``. .. py:property:: choices .. py:attribute:: description .. py:method:: _generate_choices() .. py:method:: deconstruct() Return enough information to recreate the field as a 4-tuple: * The name of the field on the model, if contribute_to_class() has been run. * The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better. * A list of positional arguments. * A dict of keyword arguments. Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types): * None, bool, str, int, float, complex, set, frozenset, list, tuple, dict * UUID * datetime.datetime (naive), datetime.date * top-level classes, top-level functions - will be referenced by their full import path * Storage instances - these have their own deconstruct() method This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined. There's no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values. .. py:class:: PhoneNumberField(*args, **kwargs) Bases: :py:obj:`django.db.models.CharField` A ``CharField`` designed to store phone numbers. .. py:method:: deconstruct() Return enough information to recreate the field as a 4-tuple: * The name of the field on the model, if contribute_to_class() has been run. * The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better. * A list of positional arguments. * A dict of keyword arguments. Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types): * None, bool, str, int, float, complex, set, frozenset, list, tuple, dict * UUID * datetime.datetime (naive), datetime.date * top-level classes, top-level functions - will be referenced by their full import path * Storage instances - these have their own deconstruct() method This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined. There's no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values. .. py:class:: PostalCodeField(*args, **kwargs) Bases: :py:obj:`django.db.models.CharField` A ``CharField`` designed to store postal codes. .. py:method:: deconstruct() Return enough information to recreate the field as a 4-tuple: * The name of the field on the model, if contribute_to_class() has been run. * The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better. * A list of positional arguments. * A dict of keyword arguments. Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types): * None, bool, str, int, float, complex, set, frozenset, list, tuple, dict * UUID * datetime.datetime (naive), datetime.date * top-level classes, top-level functions - will be referenced by their full import path * Storage instances - these have their own deconstruct() method This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined. There's no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values.