A foundational structure for CMS systems. Helps you to create page models, components (individual content blocks to build up pages) and to attach components to pages.
Project description
django-mc
=========
|pypi-badge| |build-status|
.. |build-status| image:: https://travis-ci.org/team23/django_mc.svg
:target: https://travis-ci.org/team23/django_mc
.. |pypi-badge| image:: https://img.shields.io/pypi/v/django-mc.svg
:target: https://pypi.python.org/pypi/django-mc
**django-mc** let's you build a CMS system that evolves around a few key ideas:
- Pages are Django models where every page represents the content of one URL.
The content of a page is mostly build up using components.
- Components are content fragments that can be part of a page, but usually
don't have their own canonical URL. Examples for components might be an
image, a pdf download, a block of text, a contact form, etc.
django-mc expects that you define different "regions" in a page that can take
components. A region might be a segment of your frontend design like "header",
"footer", "sidebar" or "content", etc. This allows you to not only fill a page
with components but also decide in which part ("region") of the page they
should be placed.
A page usually also has a layout assigned. A layout is also just a model that
may define multiple components in different regions. The final contents of the
rendered page will then be a combination of the components from the page and
from the page layout. The layout more or less defines the fallback components
for a region that should be displayed if one region in the page has no
components assigned.
A model that can hold components (i.e. layouts and pages) is called a
component provider (see ``django_mc.models.RegionComponentProvider``).
django_mc is unopinionated about how you display and manage the data inside the
user facing backend. This means you can use whatever administration interface
you want. A good fit though might be ``django_backend``.
Development
-----------
Create a virtual environment, then install ``django-mc`` and its dependencies with::
Install the dependencies (including the test dependencies) with::
pip install -r requirements.txt
Then you can run all tests with::
tox
Changelog
=========
0.1.0
-----
- Added ``django_mc.link`` sub-application.
- Added ``AddComponentTypeToRegions`` and ``RemoveComponentTypeFromRegions``
to make it super easy to add and remove component types to and from the list of
allowed components in a region.
- Initial release.
=========
|pypi-badge| |build-status|
.. |build-status| image:: https://travis-ci.org/team23/django_mc.svg
:target: https://travis-ci.org/team23/django_mc
.. |pypi-badge| image:: https://img.shields.io/pypi/v/django-mc.svg
:target: https://pypi.python.org/pypi/django-mc
**django-mc** let's you build a CMS system that evolves around a few key ideas:
- Pages are Django models where every page represents the content of one URL.
The content of a page is mostly build up using components.
- Components are content fragments that can be part of a page, but usually
don't have their own canonical URL. Examples for components might be an
image, a pdf download, a block of text, a contact form, etc.
django-mc expects that you define different "regions" in a page that can take
components. A region might be a segment of your frontend design like "header",
"footer", "sidebar" or "content", etc. This allows you to not only fill a page
with components but also decide in which part ("region") of the page they
should be placed.
A page usually also has a layout assigned. A layout is also just a model that
may define multiple components in different regions. The final contents of the
rendered page will then be a combination of the components from the page and
from the page layout. The layout more or less defines the fallback components
for a region that should be displayed if one region in the page has no
components assigned.
A model that can hold components (i.e. layouts and pages) is called a
component provider (see ``django_mc.models.RegionComponentProvider``).
django_mc is unopinionated about how you display and manage the data inside the
user facing backend. This means you can use whatever administration interface
you want. A good fit though might be ``django_backend``.
Development
-----------
Create a virtual environment, then install ``django-mc`` and its dependencies with::
Install the dependencies (including the test dependencies) with::
pip install -r requirements.txt
Then you can run all tests with::
tox
Changelog
=========
0.1.0
-----
- Added ``django_mc.link`` sub-application.
- Added ``AddComponentTypeToRegions`` and ``RemoveComponentTypeFromRegions``
to make it super easy to add and remove component types to and from the list of
allowed components in a region.
- Initial release.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
django-mc-0.1.0.tar.gz
(18.2 kB
view details)
File details
Details for the file django-mc-0.1.0.tar.gz
.
File metadata
- Download URL: django-mc-0.1.0.tar.gz
- Upload date:
- Size: 18.2 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | d43af60ad947fff0a0c88a42c1367f77d6d75d6696703e4eb44e96b862fced3f |
|
MD5 | bbc9f3b2257f3d3c7a7aa87a4b2dbd90 |
|
BLAKE2b-256 | 4226a2950a00c3bd74103bed07be4ea63d603c705208a4b563fe56b11623150f |