kopia lustrzana https://github.com/wagtail/wagtail
144 wiersze
5.9 KiB
ReStructuredText
144 wiersze
5.9 KiB
ReStructuredText
====================
|
|
Creating page models
|
|
====================
|
|
|
|
Each page type (a.k.a Content type) in Wagtail is represented by a Django model. All page models must inherit from the :class:`wagtail.wagtailcore.models.Page` class.
|
|
|
|
As all page types are Django models, you can use any field type that Django provides. See `Model field reference <https://docs.djangoproject.com/en/1.7/ref/models/fields/>`_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.wagtailcore.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content.
|
|
|
|
|
|
.. topic:: Django models
|
|
|
|
If you're not yet familiar with Django models, have a quick look at the following links to get you started:
|
|
`Creating models <https://docs.djangoproject.com/en/1.7/intro/tutorial01/#creating-models>`_
|
|
`Model syntax <https://docs.djangoproject.com/en/1.7/topics/db/models/>`_
|
|
|
|
|
|
An example Wagtail Page Model
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This example represents a typical blog post:
|
|
|
|
.. code-block:: python
|
|
|
|
from django.db import models
|
|
|
|
from wagtail.wagtailcore.models import Page
|
|
from wagtail.wagtailcore.fields import RichTextField
|
|
from wagtail.wagtailadmin.edit_handlers import FieldPanel, MultiFieldPanel
|
|
from wagtail.wagtailimages.edit_handlers import ImageChooserPanel
|
|
|
|
|
|
class BlogPage(Page):
|
|
body = RichTextField()
|
|
date = models.DateField("Post date")
|
|
feed_image = models.ForeignKey(
|
|
'wagtailimages.Image',
|
|
null=True,
|
|
blank=True,
|
|
on_delete=models.SET_NULL,
|
|
related_name='+'
|
|
)
|
|
|
|
content_panels = Page.content_panels + [
|
|
FieldPanel('date'),
|
|
FieldPanel('body', classname="full"),
|
|
]
|
|
|
|
promote_panels = [
|
|
MultiFieldPanel(Page.promote_panels, "Common page configuration"),
|
|
ImageChooserPanel('feed_image'),
|
|
]
|
|
|
|
.. tip::
|
|
To keep track of ``Page`` models and avoid class name clashes, it can be helpful to suffix model class names with "Page" e.g BlogPage, ListingIndexPage.
|
|
|
|
In the example above the ``BlogPage`` class defines three properties: ``body``, ``date``, and ``feed_image``. These are a mix of basic Django models (``DateField``), Wagtail fields (:class:`~wagtail.wagtailcore.fields.RichTextField`), and a pointer to a Wagtail model (:class:`~wagtail.wagtailimages.models.Image`).
|
|
|
|
Below that the ``content_panels`` and ``promote_panels`` lists define the capabilities and layout of the page editing interface in the Wagtail admin. The lists are filled with "panels" and "choosers", which will provide a fine-grain interface for inputting the model's content. The :class:`~wagtail.wagtailimages.edit_handlers.ImageChooserPanel`, for instance, lets one browse the image library, upload new images and input image metadata. The :class:`~wagtail.wagtailcore.fields.RichTextField` is the basic field for creating web-ready website rich text, including text formatting and embedded media like images and video. The Wagtail admin offers other choices for fields, Panels, and Choosers, with the option of creating your own to precisely fit your content without workarounds or other compromises.
|
|
|
|
Your models may be even more complex, with methods overriding the built-in functionality of the :class:`~wagtail.wagtailcore.models.Page` to achieve webdev magic. Or, you can keep your models simple and let Wagtail's built-in functionality do the work.
|
|
|
|
|
|
Tips
|
|
~~~~
|
|
|
|
Friendly model names
|
|
--------------------
|
|
|
|
Make your model names more friendly to users of Wagtail using Django's internal ``Meta`` class with a ``verbose_name`` e.g
|
|
|
|
.. code-block:: python
|
|
|
|
class HomePage(Page):
|
|
...
|
|
|
|
class Meta:
|
|
verbose_name = "homepage"
|
|
|
|
When users are given a choice of pages to create, the list of page types is generated by splitting your model names on each of their capital letters. Thus a ``HomePage`` model would be named "Home Page" which is a little clumsy. ``verbose_name`` as in the example above, would change this to read "Homepage" which is slightly more conventional.
|
|
|
|
|
|
Page QuerySet ordering
|
|
----------------------
|
|
|
|
``Page``-derived models *cannot* be given a default ordering by using the standard Django approach of adding an ``ordering`` attribute to the internal ``Meta`` class.
|
|
|
|
.. code-block:: python
|
|
|
|
class NewsItemPage(Page):
|
|
publication_date = models.DateField()
|
|
...
|
|
|
|
class Meta:
|
|
ordering = ('-publication_date', ) # will not work
|
|
|
|
This is because ``Page`` enforces ordering QuerySets by path. Instead you must apply the ordering explicitly when you construct a QuerySet:
|
|
|
|
.. code-block:: python
|
|
|
|
news_items = NewsItemPage.objects.live().order_by('-publication_date')
|
|
|
|
Page custom managers
|
|
--------------------
|
|
|
|
``Page`` enforces its own 'objects' manager in its ``__init__`` method, so you cannot add a custom manager at the 'objects' attribute.
|
|
|
|
.. code-block:: python
|
|
|
|
class EventPageQuerySet(PageQuerySet):
|
|
|
|
def future(self):
|
|
return self.filter(
|
|
start_date__gte=timezone.localtime(timezone.now()).date()
|
|
)
|
|
|
|
class EventPage(Page):
|
|
start_date = models.DateField()
|
|
|
|
objects = EventPageQuerySet.as_manager() # will not work
|
|
|
|
To use a custom manager you must choose a different attribute name. Make sure to subclass ``wagtail.wagtailcore.models.PageManager``.
|
|
|
|
.. code-block:: python
|
|
|
|
from django.db import models
|
|
from django.utils import timezone
|
|
from wagtail.wagtailcore.models import Page, PageManager
|
|
|
|
|
|
class FutureEventPageManager(PageManager):
|
|
|
|
def get_queryset(self):
|
|
return super().get_queryset().filter(
|
|
start_date__gte=timezone.localtime(timezone.now()).date()
|
|
)
|
|
|
|
|
|
class EventPage(Page):
|
|
start_date = models.DateField()
|
|
|
|
future_events = FutureEventPageManager()
|
|
|
|
Then you can use ``EventPage.future_events`` in the manner you might expect.
|