Documentation - Clean up minor formatting issues

pull/10072/head
LB Johnston 2023-03-21 07:52:21 +10:00 zatwierdzone przez LB (Ben Johnston)
rodzic d51ec00ce1
commit 65f2eaa4d2
4 zmienionych plików z 4 dodań i 6 usunięć

Wyświetl plik

@ -4,7 +4,7 @@
## Customising the tabbed interface
As standard, Wagtail organises panels for pages into two tabs: 'Content' and 'Promote'. For snippets Wagtail puts all panels into one page. Depending on the requirements of your site, you may wish to customise this for specific page types or snippets - for example, adding an additional tab for sidebar content. This can be done by specifying an ``edit_handler`` attribute on the page or snippet model. For example:
As standard, Wagtail organises panels for pages into two tabs: 'Content' and 'Promote'. For snippets Wagtail puts all panels into one page. Depending on the requirements of your site, you may wish to customise this for specific page types or snippets - for example, adding an additional tab for sidebar content. This can be done by specifying an `edit_handler` attribute on the page or snippet model. For example:
```python
from wagtail.admin.panels import TabbedInterface, ObjectList

Wyświetl plik

@ -29,8 +29,8 @@ class LinkBlock(StructBlock):
In the above example, an exception of type `ValidationError` is raised, which causes the error to be attached and rendered against the StructBlock as a whole. For more control over where the error appears, the exception class `wagtail.blocks.StructBlockValidationError` can be raised instead. The constructor for this class accepts the following arguments:
* `non_block_errors` - a list of error messages or `ValidationError` instances to be raised against the StructBlock as a whole
* `block_errors` - a dict of `ValidationError` instances to be displayed against specific child blocks of the StructBlock, where the key is the child block's name
- `non_block_errors` - a list of error messages or `ValidationError` instances to be raised against the StructBlock as a whole
- `block_errors` - a dict of `ValidationError` instances to be displayed against specific child blocks of the StructBlock, where the key is the child block's name
The following example demonstrates raising a validation error attached to the 'description' block within the StructBlock:

Wyświetl plik

@ -125,7 +125,6 @@ Here are some Wagtail-specific types that you might include as fields in your mo
Note that you can use `classname="collapsed"` to load the panel collapsed under its heading in order to save space in the Wagtail admin.
(multiple_chooser_panel)=
### MultipleChooserPanel
@ -344,4 +343,3 @@ To make input or chooser selection mandatory for a field, add [`blank=False`](dj
### Hiding Fields
Without a panel definition, a default form field (without label) will be used to represent your fields. If you intend to hide a field on the Wagtail page editor, define the field with [`editable=False`](django.db.models.Field.editable).

Wyświetl plik

@ -382,6 +382,7 @@ The first argument must match the value of the `related_name` attribute of the `
For a brief description of parameters taken by `InlinePanel`, see {ref}`inline_panels`.
## Re-using inline models across multiple page types
In the above example, related links are defined as a child object on the `BlogPage` page type. Often, the same kind of inline child object will appear on several page types, and in these cases, it's undesirable to repeat the entire model definition. This can be avoided by refactoring the common fields into an abstract model:
```python
@ -424,7 +425,6 @@ class RelatedLink(Orderable):
This will then make `related_links` available as a relation across all page types, although it will still only be editable on page types that include the `InlinePanel` in their panel definitions - for other page types, the set of related links will remain empty.
## Working with pages
Wagtail uses Django's [multi-table inheritance](https://docs.djangoproject.com/en/stable/topics/db/models/#multi-table-inheritance) feature to allow multiple page models to be used in the same tree.