Browse Source

Replace mentions of ModelAdmin with their snippets equivalent

Sage Abdullah 1 year ago
parent
commit
0c075fb8de
3 changed files with 11 additions and 9 deletions
  1. 1 1
      docs/extending/admin_views.md
  2. 1 1
      docs/extending/forms.md
  3. 9 7
      docs/reference/pages/model_recipes.md

+ 1 - 1
docs/extending/admin_views.md

@@ -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.
 

+ 1 - 1
docs/extending/forms.md

@@ -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:

+ 9 - 7
docs/reference/pages/model_recipes.md

@@ -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.