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.
Metadata
Release files for django-mc 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| django-mc-0.1.0.tar.gz | 18.2 kB | Without provenance | Details |
Release files / django-mc-0.1.0.tar.gz
| Download URL | django-mc-0.1.0.tar.gz |
|---|---|
| Size | 18.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
d43af60ad947fff0a0c88a42c1367f77d6d75d6696703e4eb44e96b862fced3f
|
|
BLAKE2b-256 checksum How to use checksums |
4226a2950a00c3bd74103bed07be4ea63d603c705208a4b563fe56b11623150f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for django-mc 0.1.0
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.