diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-django-appdata.spec | 623 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 625 insertions, 0 deletions
@@ -0,0 +1 @@ +/django-appdata-0.3.2.tar.gz diff --git a/python-django-appdata.spec b/python-django-appdata.spec new file mode 100644 index 0000000..eab972f --- /dev/null +++ b/python-django-appdata.spec @@ -0,0 +1,623 @@ +%global _empty_manifest_terminate_build 0 +Name: python-django-appdata +Version: 0.3.2 +Release: 1 +Summary: Extendable field that enables Django apps to store their data on your models. +License: BSD +URL: https://github.com/ella/django-appdata/ +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/86/41/bfeab51479786f557d6880f4a4cb80875a171ce15b94390d4b8c208f7125/django-appdata-0.3.2.tar.gz +BuildArch: noarch + +Requires: python3-Django +Requires: python3-six + +%description +Django AppData +############## + +Extandable field and related tools that enable Django apps to extend your +reusable app. + +Motivation +********** + +When working with reusable django apps we often found that we needed to add +something extra to the model or form the app provided. Some apps try to solve +this by providing a flexible model definition and a pluggable form (see +``django.contrib.comments`` for an exmple of this approach) but even then it +leads to some duplication of efforts. + +``django-appdata`` app tries, through ``AppDataField``, ``MultiForm`` and ``AppDataModelAdmin``, +to provide a standardised approach to extending existing apps. + +Supported versions +****************** + +Python: 2.7, 3.5, 3.6, 3.7, 3.8 +Django: 1.11, 2.2, 3.0, 3.1 + +Upgrading to 0.3 +**************** + +If you are upgrading from a 0.2.x version, please note the following incompatible changes in 0.3 + +* Dropped Django < 1.11 and Python 3.4 compatibility + + +Extending Models +**************** + +When you have an extendable django app using the ``AppDataField``:: + + from django.db import models + from app_data import AppDataField + + class BlogPost(models.Model): + text = models.TextField() + app_data = AppDataField() + +your code can register a namespace on any (or all) ``AppDataField`` and store +it's own data there by registering a *container* (subclass of +``AppDataContainer``). To define the data you use django's form framework:: + + from django.forms.models import ModelMultipleChoiceField + from app_data import app_registry, AppDataForm, AppDataContainer + + from .models import Tag + + class TaggingAppDataForm(AppDataForm): + public_tags = ModelMultipleChoiceField(Tag.objects.all()) + admin_tags = ModelMultipleChoiceField(Tag.objects.all()) + + class TaggingAppDataContainer(AppDataContainer): + form_class = TaggingAppDataForm + + def tag_string(self): + print ', '.join(t.name for t in self.public_tags) + + app_registry.register('tagging', TaggingAppDataContainer) + +This should give you access to ``'tagging'`` namespace in any defined ``AppDataField``:: + + from blog_app.models import BlogPost + + bp = BlogPost() + assert bp.app_data.tagging.tag_string() == "" + + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Note that if you don't need to add custom methods to your container you can +just use a factory to create the subclass:: + + app_registry.register('tagging', AppDataContainer.from_form(TaggingAppDataForm)) + +Additionaly you can restrict the registration to a given model:: + + from blog_app.models import BlogPost + + app_registry.register('tagging', TaggingAppDataContainer, BlogPost) + +Extending Forms +*************** + +``django-appdata`` supplies a ``MultiForm`` class - a wrapper around django's ``ModelForm`` +with optional added sub-forms that corresponds to namespaces registered in the +model's ``AppDataField``, typically the extendable app would create and use a +``MultiForm`` instead of a regular ``ModelForm``:: + + from app_data.forms import multiform_factory + from .models import BlogPost + + BlogPostMultiForm = multiform_factory(BlogPost) + +And when using that app any project can add additional sub-forms to that ``MultiForm``:: + + from blog_app.forms import BlogPostMultiForm + + BlogPostMultiForm.add_form('tagging', {'fields': ['public_tags']}) + +This way when the reusable app's code can remain unchanged and we can inject +additional form logic to its processing. + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Any arguments and keyword arguments are passed without change to the +``ModelForm`` class the ``MultiForm`` is wrapping so even if you have custom args +for your ``ModelForm`` everything will still work:: + + from django.forms.models import BaseModelForm + + class ModelFormWithUser(ModelForm): + def __init__(self, user, *args, **kwargs): + self.user = user + super(ModelFormWithUser, self).__init__(*args, **kwargs) + + BlogPostMultiForm = multiform_factory(BlogPost, form=ModelFormWithUser) + +And of course you are not limited to the use of a factory function:: + + from app_data import MultiForm + + class MyMultiForm(MultiForm): + ModelForm = BlogPostModelForm + +MultiForms in Admin +******************* + +If you wish to add your own code to the admin interface, just use +``AppDataModelAdmin``:: + + from django.contrib import admin + from app_data.admin import AppDataModelAdmin + from blog_app.models import BlogPost + + class BlogPostAdmin(AppDataModelAdmin): + # due to the behavior of django admin validation we need to use + # get_fieldsets instead of just fieldsets + def get_fieldsets(self, request, obj=None): + return [ + (None, {'fields': ['text', ]}), + ('Tagging', {'fields': [('tagging.public_tags', 'tagging.admin_tags')]}) + ] + admin.site.register(BlogPost, BlogPostAdmin) + +Additional Options +~~~~~~~~~~~~~~~~~~ + +As with django's admin and forms you can supply your own ``MultiForm`` class by +using the ``multiform`` attribute of ``AppDataModelAdmin``. + +Behind the scenes +***************** + +``django-appdata`` uses a ``TextField`` to store the data on the model using JSON +and django's forms framework for (de)serialization and validation of the data. + +When accessing the containers in the field we will try to locate the +appropriate container in the registry. If none is found, plain data will be +returned if present (dict). To assure everything working properly we recommend +putting some sort of init code in place for your project that will make sure all +the registration is done before any actual code is run. We are using a module +called ``register`` in our apps and then a `piece of code`_ similar to admin's +autodiscover to iterate through installed apps and load this module. + +.. _`piece of code`: https://github.com/ella/ella/blob/master/ella/utils/installedapps.py#L27 + +Build status +************ + +:Master branch: + + .. image:: https://secure.travis-ci.org/ella/django-appdata.png?branch=master + :alt: Travis CI - Distributed build platform for the open source community + :target: http://travis-ci.org/#!/ella/django-appdata + + + +%package -n python3-django-appdata +Summary: Extendable field that enables Django apps to store their data on your models. +Provides: python-django-appdata +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-django-appdata +Django AppData +############## + +Extandable field and related tools that enable Django apps to extend your +reusable app. + +Motivation +********** + +When working with reusable django apps we often found that we needed to add +something extra to the model or form the app provided. Some apps try to solve +this by providing a flexible model definition and a pluggable form (see +``django.contrib.comments`` for an exmple of this approach) but even then it +leads to some duplication of efforts. + +``django-appdata`` app tries, through ``AppDataField``, ``MultiForm`` and ``AppDataModelAdmin``, +to provide a standardised approach to extending existing apps. + +Supported versions +****************** + +Python: 2.7, 3.5, 3.6, 3.7, 3.8 +Django: 1.11, 2.2, 3.0, 3.1 + +Upgrading to 0.3 +**************** + +If you are upgrading from a 0.2.x version, please note the following incompatible changes in 0.3 + +* Dropped Django < 1.11 and Python 3.4 compatibility + + +Extending Models +**************** + +When you have an extendable django app using the ``AppDataField``:: + + from django.db import models + from app_data import AppDataField + + class BlogPost(models.Model): + text = models.TextField() + app_data = AppDataField() + +your code can register a namespace on any (or all) ``AppDataField`` and store +it's own data there by registering a *container* (subclass of +``AppDataContainer``). To define the data you use django's form framework:: + + from django.forms.models import ModelMultipleChoiceField + from app_data import app_registry, AppDataForm, AppDataContainer + + from .models import Tag + + class TaggingAppDataForm(AppDataForm): + public_tags = ModelMultipleChoiceField(Tag.objects.all()) + admin_tags = ModelMultipleChoiceField(Tag.objects.all()) + + class TaggingAppDataContainer(AppDataContainer): + form_class = TaggingAppDataForm + + def tag_string(self): + print ', '.join(t.name for t in self.public_tags) + + app_registry.register('tagging', TaggingAppDataContainer) + +This should give you access to ``'tagging'`` namespace in any defined ``AppDataField``:: + + from blog_app.models import BlogPost + + bp = BlogPost() + assert bp.app_data.tagging.tag_string() == "" + + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Note that if you don't need to add custom methods to your container you can +just use a factory to create the subclass:: + + app_registry.register('tagging', AppDataContainer.from_form(TaggingAppDataForm)) + +Additionaly you can restrict the registration to a given model:: + + from blog_app.models import BlogPost + + app_registry.register('tagging', TaggingAppDataContainer, BlogPost) + +Extending Forms +*************** + +``django-appdata`` supplies a ``MultiForm`` class - a wrapper around django's ``ModelForm`` +with optional added sub-forms that corresponds to namespaces registered in the +model's ``AppDataField``, typically the extendable app would create and use a +``MultiForm`` instead of a regular ``ModelForm``:: + + from app_data.forms import multiform_factory + from .models import BlogPost + + BlogPostMultiForm = multiform_factory(BlogPost) + +And when using that app any project can add additional sub-forms to that ``MultiForm``:: + + from blog_app.forms import BlogPostMultiForm + + BlogPostMultiForm.add_form('tagging', {'fields': ['public_tags']}) + +This way when the reusable app's code can remain unchanged and we can inject +additional form logic to its processing. + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Any arguments and keyword arguments are passed without change to the +``ModelForm`` class the ``MultiForm`` is wrapping so even if you have custom args +for your ``ModelForm`` everything will still work:: + + from django.forms.models import BaseModelForm + + class ModelFormWithUser(ModelForm): + def __init__(self, user, *args, **kwargs): + self.user = user + super(ModelFormWithUser, self).__init__(*args, **kwargs) + + BlogPostMultiForm = multiform_factory(BlogPost, form=ModelFormWithUser) + +And of course you are not limited to the use of a factory function:: + + from app_data import MultiForm + + class MyMultiForm(MultiForm): + ModelForm = BlogPostModelForm + +MultiForms in Admin +******************* + +If you wish to add your own code to the admin interface, just use +``AppDataModelAdmin``:: + + from django.contrib import admin + from app_data.admin import AppDataModelAdmin + from blog_app.models import BlogPost + + class BlogPostAdmin(AppDataModelAdmin): + # due to the behavior of django admin validation we need to use + # get_fieldsets instead of just fieldsets + def get_fieldsets(self, request, obj=None): + return [ + (None, {'fields': ['text', ]}), + ('Tagging', {'fields': [('tagging.public_tags', 'tagging.admin_tags')]}) + ] + admin.site.register(BlogPost, BlogPostAdmin) + +Additional Options +~~~~~~~~~~~~~~~~~~ + +As with django's admin and forms you can supply your own ``MultiForm`` class by +using the ``multiform`` attribute of ``AppDataModelAdmin``. + +Behind the scenes +***************** + +``django-appdata`` uses a ``TextField`` to store the data on the model using JSON +and django's forms framework for (de)serialization and validation of the data. + +When accessing the containers in the field we will try to locate the +appropriate container in the registry. If none is found, plain data will be +returned if present (dict). To assure everything working properly we recommend +putting some sort of init code in place for your project that will make sure all +the registration is done before any actual code is run. We are using a module +called ``register`` in our apps and then a `piece of code`_ similar to admin's +autodiscover to iterate through installed apps and load this module. + +.. _`piece of code`: https://github.com/ella/ella/blob/master/ella/utils/installedapps.py#L27 + +Build status +************ + +:Master branch: + + .. image:: https://secure.travis-ci.org/ella/django-appdata.png?branch=master + :alt: Travis CI - Distributed build platform for the open source community + :target: http://travis-ci.org/#!/ella/django-appdata + + + +%package help +Summary: Development documents and examples for django-appdata +Provides: python3-django-appdata-doc +%description help +Django AppData +############## + +Extandable field and related tools that enable Django apps to extend your +reusable app. + +Motivation +********** + +When working with reusable django apps we often found that we needed to add +something extra to the model or form the app provided. Some apps try to solve +this by providing a flexible model definition and a pluggable form (see +``django.contrib.comments`` for an exmple of this approach) but even then it +leads to some duplication of efforts. + +``django-appdata`` app tries, through ``AppDataField``, ``MultiForm`` and ``AppDataModelAdmin``, +to provide a standardised approach to extending existing apps. + +Supported versions +****************** + +Python: 2.7, 3.5, 3.6, 3.7, 3.8 +Django: 1.11, 2.2, 3.0, 3.1 + +Upgrading to 0.3 +**************** + +If you are upgrading from a 0.2.x version, please note the following incompatible changes in 0.3 + +* Dropped Django < 1.11 and Python 3.4 compatibility + + +Extending Models +**************** + +When you have an extendable django app using the ``AppDataField``:: + + from django.db import models + from app_data import AppDataField + + class BlogPost(models.Model): + text = models.TextField() + app_data = AppDataField() + +your code can register a namespace on any (or all) ``AppDataField`` and store +it's own data there by registering a *container* (subclass of +``AppDataContainer``). To define the data you use django's form framework:: + + from django.forms.models import ModelMultipleChoiceField + from app_data import app_registry, AppDataForm, AppDataContainer + + from .models import Tag + + class TaggingAppDataForm(AppDataForm): + public_tags = ModelMultipleChoiceField(Tag.objects.all()) + admin_tags = ModelMultipleChoiceField(Tag.objects.all()) + + class TaggingAppDataContainer(AppDataContainer): + form_class = TaggingAppDataForm + + def tag_string(self): + print ', '.join(t.name for t in self.public_tags) + + app_registry.register('tagging', TaggingAppDataContainer) + +This should give you access to ``'tagging'`` namespace in any defined ``AppDataField``:: + + from blog_app.models import BlogPost + + bp = BlogPost() + assert bp.app_data.tagging.tag_string() == "" + + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Note that if you don't need to add custom methods to your container you can +just use a factory to create the subclass:: + + app_registry.register('tagging', AppDataContainer.from_form(TaggingAppDataForm)) + +Additionaly you can restrict the registration to a given model:: + + from blog_app.models import BlogPost + + app_registry.register('tagging', TaggingAppDataContainer, BlogPost) + +Extending Forms +*************** + +``django-appdata`` supplies a ``MultiForm`` class - a wrapper around django's ``ModelForm`` +with optional added sub-forms that corresponds to namespaces registered in the +model's ``AppDataField``, typically the extendable app would create and use a +``MultiForm`` instead of a regular ``ModelForm``:: + + from app_data.forms import multiform_factory + from .models import BlogPost + + BlogPostMultiForm = multiform_factory(BlogPost) + +And when using that app any project can add additional sub-forms to that ``MultiForm``:: + + from blog_app.forms import BlogPostMultiForm + + BlogPostMultiForm.add_form('tagging', {'fields': ['public_tags']}) + +This way when the reusable app's code can remain unchanged and we can inject +additional form logic to its processing. + +Additional Options +~~~~~~~~~~~~~~~~~~ + +Any arguments and keyword arguments are passed without change to the +``ModelForm`` class the ``MultiForm`` is wrapping so even if you have custom args +for your ``ModelForm`` everything will still work:: + + from django.forms.models import BaseModelForm + + class ModelFormWithUser(ModelForm): + def __init__(self, user, *args, **kwargs): + self.user = user + super(ModelFormWithUser, self).__init__(*args, **kwargs) + + BlogPostMultiForm = multiform_factory(BlogPost, form=ModelFormWithUser) + +And of course you are not limited to the use of a factory function:: + + from app_data import MultiForm + + class MyMultiForm(MultiForm): + ModelForm = BlogPostModelForm + +MultiForms in Admin +******************* + +If you wish to add your own code to the admin interface, just use +``AppDataModelAdmin``:: + + from django.contrib import admin + from app_data.admin import AppDataModelAdmin + from blog_app.models import BlogPost + + class BlogPostAdmin(AppDataModelAdmin): + # due to the behavior of django admin validation we need to use + # get_fieldsets instead of just fieldsets + def get_fieldsets(self, request, obj=None): + return [ + (None, {'fields': ['text', ]}), + ('Tagging', {'fields': [('tagging.public_tags', 'tagging.admin_tags')]}) + ] + admin.site.register(BlogPost, BlogPostAdmin) + +Additional Options +~~~~~~~~~~~~~~~~~~ + +As with django's admin and forms you can supply your own ``MultiForm`` class by +using the ``multiform`` attribute of ``AppDataModelAdmin``. + +Behind the scenes +***************** + +``django-appdata`` uses a ``TextField`` to store the data on the model using JSON +and django's forms framework for (de)serialization and validation of the data. + +When accessing the containers in the field we will try to locate the +appropriate container in the registry. If none is found, plain data will be +returned if present (dict). To assure everything working properly we recommend +putting some sort of init code in place for your project that will make sure all +the registration is done before any actual code is run. We are using a module +called ``register`` in our apps and then a `piece of code`_ similar to admin's +autodiscover to iterate through installed apps and load this module. + +.. _`piece of code`: https://github.com/ella/ella/blob/master/ella/utils/installedapps.py#L27 + +Build status +************ + +:Master branch: + + .. image:: https://secure.travis-ci.org/ella/django-appdata.png?branch=master + :alt: Travis CI - Distributed build platform for the open source community + :target: http://travis-ci.org/#!/ella/django-appdata + + + +%prep +%autosetup -n django-appdata-0.3.2 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-django-appdata -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Wed Apr 12 2023 Python_Bot <Python_Bot@openeuler.org> - 0.3.2-1 +- Package Spec generated @@ -0,0 +1 @@ +c8e706ffa80ccd18b9aee9036707e932 django-appdata-0.3.2.tar.gz |