kopia lustrzana https://github.com/wagtail/wagtail
Replace mentions of ModelAdmin with their snippets equivalent
rodzic
f2accc89e3
commit
0c075fb8de
|
@ -1,6 +1,6 @@
|
|||
# Creating admin views
|
||||
|
||||
The most common use for adding custom views to the Wagtail admin is to provide an interface for managing a Django model. The [](../reference/contrib/modeladmin/index) app makes this simple, providing ready-made views for listing, creating, and editing objects with minimal configuration.
|
||||
The most common use for adding custom views to the Wagtail admin is to provide an interface for managing a Django model. Using [](snippets), Wagtail provides ready-made views for listing, creating, and editing Django models with minimal configuration.
|
||||
|
||||
For other kinds of admin views that don't fit this pattern, you can write your own Django views and register them as part of the Wagtail admin through [hooks](admin_hooks). In this example, we'll implement a view that displays a calendar for the current year, using [the calendar module](https://docs.python.org/3/library/calendar.html) from Python's standard library.
|
||||
|
||||
|
|
|
@ -64,7 +64,7 @@ See [](/reference/pages/panels) for the set of panel types provided by Wagtail.
|
|||
|
||||
A view performs the following steps to render a model form through the panels mechanism:
|
||||
|
||||
- The top-level panel object for the model is retrieved. Usually this is done by looking up the model's `edit_handler` property and falling back on an `ObjectList` consisting of children given by the model's `panels` property. However, it may come from elsewhere - for example, the ModelAdmin module allows defining it on the ModelAdmin configuration object.
|
||||
- The top-level panel object for the model is retrieved. Usually this is done by looking up the model's `edit_handler` property and falling back on an `ObjectList` consisting of children given by the model's `panels` property. However, it may come from elsewhere - for example, snippets can define their panels via the `SnippetViewSet` class.
|
||||
- If the `PanelsGroup`s permissions do not allow a user to see this panel, then nothing more will be done.
|
||||
- The view calls `bind_to_model` on the top-level panel, passing the model class, and this returns a clone of the panel with a `model` property. As part of this process the `on_model_bound` method is invoked on each child panel, to allow it to perform additional initialisation that requires access to the model (for example, this is where `FieldPanel` retrieves the model field definition).
|
||||
- The view then calls `get_form_class` on the top-level panel to retrieve a ModelForm subclass that can be used to edit the model. This proceeds as follows:
|
||||
|
|
|
@ -248,30 +248,32 @@ class BlogTag(TagBase):
|
|||
|
||||
Here we have registered `BlogTag` as a snippet, to provide an interface for administrators (and other users with the appropriate permissions) to manage the allowed set of tags. With the `free_tagging = False` option set, editors can no longer enter arbitrary text into the tag field, and must instead select existing tags from the autocomplete dropdown.
|
||||
|
||||
### Managing tags with Wagtail's `ModelAdmin`
|
||||
### Managing tags as snippets
|
||||
|
||||
In order to manage all the tags used in a project, you can a use the `ModelAdmin` to add the `Tag` model to the Wagtail admin. This will allow you to have a tag admin interface within the main menu in which you can add, edit or delete your tags.
|
||||
In order to manage all the tags used in a project, you can register the `Tag` model as a snippet to be managed via the Wagtail admin. This will allow you to have a tag admin interface within the main menu in which you can add, edit or delete your tags.
|
||||
|
||||
Tags that are removed from a content don't get deleted from the `Tag` model and will still be shown in typeahead tag completion. So having a tag interface is a great way to completely get rid of tags you don't need.
|
||||
|
||||
To add the tag interface, add the following block of code to a `wagtail_hooks.py` file within any your project’s apps:
|
||||
|
||||
```python
|
||||
from wagtail.contrib.modeladmin.options import ModelAdmin, modeladmin_register
|
||||
from wagtail.admin.panels import FieldPanel
|
||||
from wagtail.snippets.models import register_snippet
|
||||
from wagtail.snippets.views.snippets import SnippetViewSet
|
||||
from taggit.models import Tag
|
||||
|
||||
|
||||
class TagsModelAdmin(ModelAdmin):
|
||||
Tag.panels = [FieldPanel("name")] # only show the name field
|
||||
class TagsSnippetViewSet(SnippetViewSet):
|
||||
panels = [FieldPanel("name")] # only show the name field
|
||||
model = Tag
|
||||
icon = "tag" # change as required
|
||||
add_to_admin_menu = True
|
||||
menu_label = "Tags"
|
||||
menu_icon = "tag" # change as required
|
||||
menu_order = 200 # will put in 3rd place (000 being 1st, 100 2nd)
|
||||
list_display = ["name", "slug"]
|
||||
search_fields = ("name",)
|
||||
|
||||
modeladmin_register(TagsModelAdmin)
|
||||
register_snippet(TagsSnippetViewSet)
|
||||
```
|
||||
|
||||
A `Tag` model has a `name` and `slug` required fields. If you decide to add a tag, it is recommended to only display the `name` field panel as the slug field is autofilled when the `name` field is filled and you don't need to enter the same name in both the fields.
|
||||
|
|
Ładowanie…
Reference in New Issue