Documentation - Reposition model & panel references

- Move model reference to directly under the references section, not the reference/pages section
- Move panel reference to directly under the references section, not the reference/pages section
- Merge panel API with panels reference pages
- Fix confusing heading levels in the page model recipes page
- Fix title in model reference to align with docs style guide
- Adopt US spelling for customize (panels) reference key
pull/12445/head
Srishti-j18 2024-10-22 10:53:07 +05:30 zatwierdzone przez LB (Ben Johnston)
rodzic 25de8011d5
commit f588fcf249
11 zmienionych plików z 60 dodań i 56 usunięć

Wyświetl plik

@ -254,7 +254,7 @@ This makes it easy for authors to run basic accessibility checks – validating
### help_text and HelpPanel
Occasional Wagtail users may not be aware of your sites content guidelines, or best practices of writing for the web. Use fields `help_text` and `HelpPanel` (see [Panel types](../reference/pages/panels)).
Occasional Wagtail users may not be aware of your sites content guidelines, or best practices of writing for the web. Use fields `help_text` and `HelpPanel` (see [Panel types](../reference/panels)).
### Readability

Wyświetl plik

@ -62,7 +62,7 @@ Wagtail's edit views for pages and snippets use `WagtailAdminModelForm` as stand
Panels (also known as edit handlers until Wagtail 3.0) are Wagtail's mechanism for specifying the content and layout of a model form without having to write a template. They are used for the editing interface for pages and snippets, as well as the [site settings](/reference/contrib/settings) contrib module.
See [](/reference/pages/panels) for the set of panel types provided by Wagtail. All panels inherit from the base class `wagtail.admin.panels.Panel`. A single panel object (usually `ObjectList` or `TabbedInterface`) exists at the top level and is the only one directly accessed by the view code; panels containing child panels inherit from the base class `wagtail.admin.panels.PanelGroup` and take care of recursively calling methods on their child panels where appropriate.
See [](/reference/panels) for the set of panel types provided by Wagtail. All panels inherit from the base class `wagtail.admin.panels.Panel`. A single panel object (usually `ObjectList` or `TabbedInterface`) exists at the top level and is the only one directly accessed by the view code; panels containing child panels inherit from the base class `wagtail.admin.panels.PanelGroup` and take care of recursively calling methods on their child panels where appropriate.
A view performs the following steps to render a model form through the panels mechanism:
@ -77,4 +77,4 @@ A view performs the following steps to render a model form through the panels me
- An instance of the form class is created as per a normal Django form view.
- The view then calls `get_bound_panel` on the top-level panel, passing `instance`, `form` and `request` as keyword arguments. This returns a `BoundPanel` object, which follows [the template component API](/extending/template_components). Finally, the `BoundPanel` object (and its media definition) is rendered onto the template.
New panel types can be defined by subclassing `wagtail.admin.panels.Panel` - see [](/reference/panel_api).
New panel types can be defined by sub-classing `wagtail.admin.panels.Panel` - see [](panels_api).

Wyświetl plik

@ -10,11 +10,12 @@ pages/index
streamfield/index
contrib/index
management_commands
models
hooks
signals
settings
project_template
jinja2
panel_api
panels
viewsets
```

Wyświetl plik

@ -1,4 +1,4 @@
# Model Reference
# Model reference
```{eval-rst}
.. automodule:: wagtail.models

Wyświetl plik

@ -12,7 +12,5 @@ maxdepth: 2
---
theory
model_recipes
panels
model_reference
queryset_reference
```

Wyświetl plik

@ -37,7 +37,7 @@ With this strategy, you could use Django or Python utilities to render your mode
(overriding_route_method)=
### Adding Endpoints with Custom {meth}`~wagtail.models.Page.route` Methods
## Adding Endpoints with Custom {meth}`~wagtail.models.Page.route` Methods
```{note}
A much simpler way of adding more endpoints to pages is provided by the [](routable_page_mixin) mixin.

Wyświetl plik

@ -1,39 +0,0 @@
# Panel API
```{eval-rst}
.. module:: wagtail.admin.panels
```
This document describes the reference API for the base `Panel` and the `BoundPanel` classes that are used to render Wagtail's panels. For available panel types and how to use them, see [](editing_api).
## `Panel`
```{eval-rst}
.. autoclass:: Panel
.. automethod:: bind_to_model
.. automethod:: on_model_bound
.. automethod:: clone
.. automethod:: clone_kwargs
.. automethod:: get_form_options
.. automethod:: get_form_class
.. automethod:: get_bound_panel
.. autoproperty:: clean_name
```
## `BoundPanel`
```{eval-rst}
.. autoclass:: wagtail.admin.panels.Panel.BoundPanel
In addition to the standard template component functionality (see :ref:`creating_template_components`), this provides the following attributes and methods:
.. autoattribute:: panel
.. autoattribute:: instance
.. autoattribute:: request
.. autoattribute:: form
.. autoattribute:: prefix
.. automethod:: id_for_label
.. automethod:: is_shown
```

Wyświetl plik

@ -1,6 +1,8 @@
(editing_api)=
(panels_reference)=
# Panel types
# Panels
(editing_api)=
## Built-in Fields and Choosers
@ -21,7 +23,7 @@ Here are some built-in panel types that you can use in your panel definitions. T
```{eval-rst}
.. autoclass:: FieldPanel
This is the panel to use for basic Django model field types. It provides a default icon and heading based on the model field definition, but they can be customized by passing additional arguments to the constructor. For more details, see :ref:`customising_panels`.
This is the panel to use for basic Django model field types. It provides a default icon and heading based on the model field definition, but they can be customized by passing additional arguments to the constructor. For more details, see :ref:`customizing_panels`.
.. attribute:: FieldPanel.field_name
@ -304,11 +306,11 @@ The `MultipleChooserPanel` definition on `BlogPage` would be:
.. autoclass:: TitleFieldPanel
This is the panel to use for Page title fields or main titles on other models. It provides a default classname, placeholder, and widget attributes to enable the automatic sync with the slug field in the form. Many of these defaults can be customized by passing additional arguments to the constructor. All the same `FieldPanel` arguments are supported including a custom widget. For more details, see :ref:`customising_panels`.
This is the panel to use for Page title fields or main titles on other models. It provides a default classname, placeholder, and widget attributes to enable the automatic sync with the slug field in the form. Many of these defaults can be customized by passing additional arguments to the constructor. All the same `FieldPanel` arguments are supported including a custom widget. For more details, see :ref:`customizing_panels`.
```
(customising_panels)=
(customizing_panels)=
## Panel customization
@ -443,3 +445,45 @@ For example, you can use the `attrs` parameter to integrate your Stimulus contro
),
]
```
(panels_api)=
## Panel API
```{eval-rst}
.. module:: wagtail.admin.panels
```
This document describes the reference API for the base `Panel` and the `BoundPanel` classes that are used to render Wagtail's panels. For available panel types and how to use them, see [](editing_api).
### `Panel`
```{eval-rst}
.. autoclass:: Panel
.. automethod:: bind_to_model
.. automethod:: on_model_bound
.. automethod:: clone
.. automethod:: clone_kwargs
.. automethod:: get_form_options
.. automethod:: get_form_class
.. automethod:: get_bound_panel
.. autoproperty:: clean_name
```
### `BoundPanel`
```{eval-rst}
.. autoclass:: wagtail.admin.panels.Panel.BoundPanel
In addition to the standard template component functionality (see :ref:`creating_template_components`), this provides the following attributes and methods:
.. autoattribute:: panel
.. autoattribute:: instance
.. autoattribute:: request
.. autoattribute:: form
.. autoattribute:: prefix
.. automethod:: id_for_label
.. automethod:: is_shown
```

Wyświetl plik

@ -92,7 +92,7 @@ StreamField definitions within migrations are now represented in a more compact
### Documentation
* Remove duplicate section on frontend caching proxies from performance page (Jake Howard)
* Document `restriction_type` field on [PageViewRestriction](../reference/pages/model_reference.md) (Shlomo Markowitz)
* Document `restriction_type` field on [PageViewRestriction](../reference/models.md) (Shlomo Markowitz)
* Document Wagtail's bug bounty policy (Jake Howard)
* Fix incorrect Sphinx-style code references to use MyST style (Byron Peebles)
* Document the fact that `Orderable` is not required for inline panels (Bojan Mihelac)

Wyświetl plik

@ -123,7 +123,7 @@ There are a few attributes for defining how the page's fields will be arranged i
Each of these attributes is set to a list of `Panel` objects, which defines which fields appear on which tabs and how they are structured on each tab.
Here's a summary of the `Panel` classes that Wagtail provides out of the box. See [Panel types](/reference/pages/panels) for full descriptions.
Here's a summary of the `Panel` classes that Wagtail provides out of the box. See [Panel types](/reference/panels) for full descriptions.
**Basic**

Wyświetl plik

@ -57,8 +57,8 @@ class Panel:
with the field list and other parameters collated from all panels in the structure.
It then handles rendering that form as HTML.
The following parameters can be used to customise how the panel is displayed.
For more details, see :ref:`customising_panels`.
The following parameters can be used to customize how the panel is displayed.
For more details, see :ref:`customizing_panels`.
:param heading: The heading text to display for the panel.
:param classname: A CSS class name to add to the panel's HTML element.