Skip to main content

djangocms-spa

Run your django CMS project as a single-page application (SPA). This package provides a REST-API that returns all page contents serialized as JSON. A couple of helpers and base classes can be used to create API endpoints for custom views. djangocms-spa was build to use it together with a concrete implementation:

Quickstart

Install djangocms_spa:

pip install djangocms-spa

Add it to your INSTALLED_APPS:

INSTALLED_APPS = (
    ...
    'djangocms_spa',
    ...
)

Add the Locale middleware (if it isn’t already):

MIDDLEWARE = (
...
'django.middleware.locale.LocaleMiddleware',
)

Set your default template:

DJANGOCMS_SPA_DEFAULT_TEMPLATE = 'pages/content.html'

The settings variable DJANGOCMS_SPA_TEMPLATES expects a dictionary of templates. It should cover all templates of CMS_TEMPLATES and use the path as key. The frontend component name and a list of partials (e.g. static placeholders) are valid options.

DJANGOCMS_SPA_TEMPLATES = {
    'pages/content.html': {
        'frontend_component_name': 'content',
        'partials': ['menu', 'meta', 'footer']
    },
    'pages/content_with_section_navigation.html': {
        'frontend_component_name': 'content-with-section-navigation',
        'partials': ['menu', 'meta', 'footer']
    },
}

Configure your custom partials:

DJANGOCMS_SPA_PARTIAL_CALLBACKS = {
    'menu': 'djangocms_spa.partial_callbacks.get_cms_menu_data_dict'
}

Render the initial app version (commit hash) in the template so your client can check it:

{% load app_version_tags %}
{% app_version %}

Plugins

Your plugins don’t need a rendering template but a render_spa method that returns a dictionary. To have a clean structure, we usually put the context inside a content key of the dictionary:

class TextPlugin(JsonOnlyPluginBase):
    name = _('Text')
    model = TextPluginModel
    frontend_component_name = 'cmp-text'
    def render_spa(self, request, context, instance):
        context = super(TextPlugin, self).render_spa(request, context, instance)
        context['content']['text']. = instance.text
        return context

plugin_pool.register_plugin(TextPlugin)

Settings

CACHE_TIMEOUT (default: 60 * 10)

If you are using a caching backend, the API responses are cached.

DJANGOCMS_SPA_DEFAULT_TEMPLATE (default: 'index.html')

DEFAULT_LIST_CONTAINER_NAME (default: 'object_list')

The list view uses this key to group its data.

CMS_PAGE_DATA_POST_PROCESSOR (default: None)

This hook allows you to post process the data of a CMS page by defining a module path.

PLACEHOLDER_DATA_POST_PROCESSOR (default: None)

This hook allows you to post process the data of a placeholder by defining a module path.

Partials

We call global page elements that are used to render a template “partial”. The contents of a partial do not change from one page to another. In a django CMS project partials are implemented as static placeholders. Because we don’t render any HTML templates, we need to configure the static placeholders for each template in DJANGOCMS_SPA_TEMPLATES as partials. To edit your placeholder and static placeholder data, you need to render both in the edit mode:

{% if request.toolbar.edit_mode_active %}
    {% placeholder "main" %}
    {% static_placeholder "footer" %}
{% endif %}

Usually there are other parts like the menu or any other template tag that work pretty much like static placeholders. Because we don’t have a template that allows us to render template tags, we need to have a custom implementation for those needs. We decided to use a callback approach that allows developers to bring custom data into the partial list. Define your callbacks in DJANGOCMS_SPA_PARTIAL_CALLBACKS by adding a partial key and the module path of the callback function. You will find an example in djangocms_spa/partial_callbacks.py. Your function should return a dictionary like this:

{
    'type': 'generic',
    'content': {
        'my_var': 1
    }
}

Credits

Tools used in rendering this package:

History

Metadata

Release files for djangocms-spa 0.1.28

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for djangocms-spa 0.1.28
File Size Uploaded Provenance
djangocms-spa-0.1.28.tar.gz 20.4 kB Without provenance Details

Release files / djangocms-spa-0.1.28.tar.gz

Download URL djangocms-spa-0.1.28.tar.gz
Size 20.4 kB
Tags Source
SHA-256 checksum
How to use checksums
11458997fc78e735d76b27540a006f6de1cc8352a1b5996660cf0db822b575d4
BLAKE2b-256 checksum
How to use checksums
a6ebceef44e46f6585266abacd5034ceea25b484f10ccee6dd67bdcec494998b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/3.4.2 importlib_metadata/4.8.1 pkginfo/1.7.1 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.9.15

Security for djangocms-spa 0.1.28

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page