useful_inkleby.useful_django.views package¶
Submodules¶
useful_inkleby.useful_django.views.bake module¶
-
class
useful_inkleby.useful_django.views.bake.
BakeView
[source]¶ Bases:
useful_inkleby.useful_django.views.functional.LogicalView
Extends functional view with baking functions.
expects a bake_args() generator that returns a series of different sets of arguments to bake into files.
expects a BAKE_LOCATION - in django settings
render_to_file() - render all possible versions of this view.
-
bake_args
(limit_query)[source]¶ subclass with a generator that feeds all possible arguments into the view
-
bake_path
= ''¶
-
-
class
useful_inkleby.useful_django.views.bake.
BaseBakeManager
(views_module=None)[source]¶ Bases:
object
Manager for bake command function Subclass as views.BakeManager to add more custom behaviour
-
class
useful_inkleby.useful_django.views.bake.
RequestMock
(**defaults)[source]¶ Bases:
django.test.client.RequestFactory
Construct a generic request object to get results of view
useful_inkleby.useful_django.views.decorators module¶
useful_inkleby.useful_django.views.functional module¶
Created on 26 Mar 2016
@author: alex
-
class
useful_inkleby.useful_django.views.functional.
FunctionalView
[source]¶ Bases:
object
Very simple class-based view that simple expects the class to have a ‘template’ variable and a ‘view’ function that expects (self, request).
Idea is to preserve cleanness of functional view logic but tidy up the most common operation.
-
access_denied_no_auth
(request)[source]¶ override to provide a better response if someone needs to login
-
access_denied_no_staff
(request)[source]¶ override to provide a better response if someone needs to be staff
-
classmethod
as_view
(decorators=True, no_auth=False)[source]¶ if decorators is True - we apply any view_decorators listed for the class if no_auth = True, we bypass staff and user testing(useful for baking)
-
static
login_test
(u)¶
-
require_login
= False¶
-
require_staff
= False¶
-
static
staff_test
(u)¶
-
template
= ''¶
-
view_decorators
= []¶
-
-
class
useful_inkleby.useful_django.views.functional.
LogicalView
[source]¶ Bases:
useful_inkleby.useful_django.views.functional.FunctionalView
Runs with class-based logic while trying to keep the guts exposed.
request becomes self.request
expects a ‘logic’ rather than a view function (no args).
giving the class an ‘args’ list of strings tells it what to convert view arguments into.
e.g. args = [‘id_no’] - will create self.id_no from the view argument. if an arg is a tuple (‘id_no’,‘5’) - will set a default value.
Use prelogic and postlogic decorators to run functions before or afer logic. These accept an optional order paramter. Lower order have priority. Default order is 5.
-
args
= []¶
-
useful_inkleby.useful_django.views.mixins module¶
-
class
useful_inkleby.useful_django.views.mixins.
MarkDownView
[source]¶ Bases:
object
allows for a basic view where a markdown files is read in and rendered
Give the class a markdown_loc variable which is the filepath to the markdown files.
use self.get_markdown() to retrieve markdown text. If using clean, it is avaliable as ‘markdown’ in the template.
-
markdown_loc
= ''¶
-
useful_inkleby.useful_django.views.social module¶
View for managing social properties of view
Bases:
object
Uses class properties for social arguments Allows inheritance. Template language can be used e.g.
share_title = “{{title}}”
Where a view has a ‘title’ variable.
run class social settings against template
useful_inkleby.useful_django.views.url module¶
IntegratedURLView - Sidestep django’s url.py based setup and integrate urls directly with view classes rather than keeping them seperate.
This will mix-in either with the functional inkleby view or the default django class-based views.
In views module you set up a series of classes that inherit from IntegratedURLView and then connect up in project url like so:
url(r’^foo/’, include_view(‘foo.views’)),
Philosophy behind this is that the current urlconf system was designed for functional views - class-based views have to hide themselves as functions with an as_view function, which is ugly. By moving responsibility for generating these to the class view it avoids awkward manual repetition and keeps all settings associated with the view in one place. Apps then don’t need a separate url.py.
-
class
useful_inkleby.useful_django.views.url.
IntegratedURLView
[source]¶ Bases:
useful_inkleby.useful_django.views.functional.LogicalView
Integrate URL configuration information into the View class.
Makes app level urls.py unnecessary.
add class level variables for:
url_pattern - regex string url_patterns - list of regex strings (optional) url_name - name for url view (for reverse lookup) url_extra_args - any extra arguments to be fed into the url function for this view.
-
classmethod
get_pattern
()[source]¶ returns a list of conf.url objects for url patterns that match this object
-
url_extra_args
= {}¶
-
url_name
= ''¶
-
url_pattern
= ''¶
-
url_patterns
= []¶
-
classmethod
Module contents¶
-
class
useful_inkleby.useful_django.views.
ComboView
[source]¶ Bases:
useful_inkleby.useful_django.views.LogicalSocialView
Backwards compatible LogicalSocialView
-
class
useful_inkleby.useful_django.views.
LogicalSocialView
[source]¶ Bases:
useful_inkleby.useful_django.views.LogicalURLView
,useful_inkleby.useful_django.views.social.SocialView
Contains baking, logical structure, and integrated URl and social mix-in
-
class
useful_inkleby.useful_django.views.
LogicalURLView
[source]¶ Bases:
useful_inkleby.useful_django.views.bake.BakeView
,useful_inkleby.useful_django.views.url.IntegratedURLView
Contains baking, logical structure, and integrated URl