Package: django-baker
Django Baker wants to help you get your projects up and running quickly.  Given one or more app names, s/he will automatically generate views, forms, urls, admin, and templates for all of the models in the models.py file.  All files are pep-8 compliant (with exception to the maximum line length rule, which I don’t agree with).Once you add a single urlpattern to your project’s URLconf, you’ll have a working list view, detail view, create view, update view, and delete view for each model in your app.Optionally you may specify which models in an app to bake if you’d rather not generate files for all of them.You can override any of the template files that are used in the ‘baking’ process in the same way that you would override any third party template.  Just create a django_baker folder inside your project’s main templates directory and create a file with the same name as any of the 9 files you wish to override, which are: detail.html, create.html, update.html, list.html, delete.html, views, urls, forms, admin, base, __init__urls, __init__views.  Hopefully their names are self explanatory.Installingpipinstalldjango-bakerAdd ‘django_baker’ to INSTALLED_APPSUsageLet’s assume your project is called TastyTreats, and has two apps, one called bread and another called pastries.pythonmanage.pybakebreadpastriesThis will generate files for all of the models in both of the apps.  You can override this by passing in models for each app.  Let’s assume your pastries app has the following models: Tart, Strudel, and Danish but you only want to bake tarts and danishes.pythonmanage.pybakebreadpastries:Tart,DanishFinally you simply need to add one or more urlpattern to your project’s URLconf.(r'^pastries/',include('pastries.urls')),will result in the following url schema:www.tastytreats.com/pastries/tarts
www.tastytreats.com/pastries/danishesalternatively you can create multiple urlpatterns to create shorter urls.(r'^tarts/',include('pastries.urls.tart_urls')),(r'^danishes/',include('pastries.urls.danish_urls')),will result in the following url schema:www.tastytreats.com/tarts
www.tastytreats.com/danishesViewsTo keep things tidy, a views directory is created, and each model is given it’s own views file (ie. tart_views.py).  An __init__ file is created that imports from each of the views files.  With the __init__ file in place, you can import from any of the individual views files the same way you would have before (ie. from bread.views import CornBreadCreateView).For convenience, almost all of the CBV methods that can be overridden are stubbed out, ready to be altered as needed.  The methods are presented in the order in which they are called. I chose to leave a couple of methods out as I couldn’t imagine any scenario in which I would want to override them.Also for convenience and easy alteration, almost all of the attributes that you can set are listed.Some other niceties:form_classis set to a ModelForm that was added to your forms.py filecontext_object_nameis set to the slugified model_name (ie. tarts for DetailView, UpdateView, and DeleteView, or tarts_list for the ListView)if your model has exactly one unique slug field, it’s used as theslug_fieldandslug_url_kwargattribute.get_success_urlreturns the url for the object’s DetailView (for DeleteView, the ListView url is returned).TemplatesThe generated templates files are kept very minimal as there aren’t usually a lot of commonalities in templates between projects.  Each extends a model base file (ie. tart_base.html) which in turn extends “base.html”, which your project is assumed to have.  The model level base file is empty but nice to have if you wish to add any html specific to that model.The ListView template lists each object, with links to view, update, or delete. There is also a link to create a new object.The DetailView template lists the object with a link to update or delete, as well as a link back to the list view.Both the CreateView and UpdateView templates display the model form with a link back to the ListView.The DeleteView template has a simple confirm required button and a link back to the ListView.FormsA ModelForm is created for each model, with many of the commonly set attributes listed for easy alteration. Thefieldsattribute is set to each field in the model other than the id.In addition, a few commonly changed methods are stubbed out, including aclean_field_namemethod for each field in the form.UrlsA new urls directory is created, with each model getting it’s own file (ie. tart_urls.py).  An __init__ file is created which adds urlpatterns that include each of the newly created urls files.  This allows you to choose whether to add routing to the app as a whole, or individually to each model (see usage above).For DetailView, UpdateView, and DeleteView, if a model has exactly one unique slug field, that slug field will be used in the url.  Otherwise pk will be used.For CreateView, UpdateView, and DeleteView, the login_required decorator has been added as the vast majority of the time these actions tend to require the user to be logged in.  In the future, I intend to make this optional.AdminThis is where I really had some fun.  For each model, a ModelAdmin is created that makes use of a model admin mixin that I wrote.  The goal of ExtendedModelAdminMixin is to make setting up a fully functional admin for each model (with intelligently chosen list_display, list_filter, and search_fields) a one liner.The actual contents of the admin.py files generated are fairly small, since most of the magic is happening in the ExtendedModelAdminMixin.  Many of the attributes that you can set are listed so that you may easily alter them as needed.  I didn’t include any of the methods you can override as there are too many and it would get way too cluttered.  There are a lot of useful ones though, which you can view here:https://docs.djangoproject.com/en/1.10/ref/contrib/admin/#modeladmin-methodsExtendedModelAdminMixin sets defaults for the following:list_select_relatedDefaults to all of the model’s ForeignKey and OneToOneFields, including those where null=True.  This will usually decrease database queries and improve page load time.You can override this by settinglist_all_select_relatedto False.list_displayDefaults to all of the model’s fields, in the order that they are listed in your models.py file, with the exception of the id field and any ManyToManyField.You can override this by setting thelist_displayattribute or you may extend it by settingextra_list_display(defaults to an empty list), the contents of which will be appended tolist_display, with any fields in both being displayed only once.In addition, each URLField, ForeignKey, and OneToOneField will display as a link.  URLFields will link to their respective urls, while ForeignKey and OneToOneFields will link to their respective object’s admin change pages.You can ovverride this functionality by settinglink_url_fieldsand/orlink_foreign_key_fieldsto False.list_filterDefaults to any field where the choices attribute has been set, as well as any field with a field type matching a field type in thelist_by_fieldsattribute (defaults to [‘BooleanField’, ‘NullBooleanField’, ‘USStateField’]), as well as any ForeignKey field where the number of related objects is less than themax_related_objectsattribute (defaults to 100).You can override this by setting thelist_filterattribute or you may extend it by settingextra_list_filter(defaults to an empty list), the contents of which will be appended tolist_filter.search_fieldsDefaults to any field with a field type matching a field type insearch_by_fields(defaults to [“CharField”, “TextField”]),You can override this by setting thesearch_fieldsattribute or you may extend it by settingextra_search_fields(defaults to an empty list), the contents of which will be appended to search_fields.NoteDjango Baker will remove 2 files (views.py, urls.py) from each app baked so long as the files are 4 lines or less (the initial size of the files when you run startapp).  This is necessary so they don’t conflict with the newly generated views and urls folders.  If the files are greater than 4 lines you will need to remove them yourself.The future of Django BakerMy top 3 todo items are:Allow apps to be baked more than once to account for newly added models.  Right now the default behavior is to only create new files and skip any steps where the file about to be baked already exists.Automatically generate tests for each app and modelAdd tests to Django Baker itselfPull requests are awesome.