Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace SnippetObjectType with SnippetInterface #405

Merged
merged 9 commits into from
Sep 24, 2024

Conversation

mgax
Copy link
Member

@mgax mgax commented Sep 20, 2024

Fixes #386

API clients could use a field on snippet objects to determine the type of snippet they are looking at. Therefore, we change the snippet type to an interface, similar to the page interface, so it can expose a new field called snippetType.

This PR includes a couple of refactoring commits which might be easier to view separately:

  1. Rename CustomInterface to AdditionalInterface: The name CustomInterface is too similar with CustomPageInterface and the upcoming CustomSnippetInterface and their custom interfaces settings file. Better rename it to AdditionalInterface so there is less confusion.
  2. Rename the custom interface settings file: The settings file will contain an override for the default snippet interface, in addition to the default page interface, so we're renaming it up front here.

The name `CustomInterface` is too similar with `CustomPageInterface` and
the upcoming `CustomSnippetInterface` and their custom interfaces
settings file. Better rename it to `AdditionalInterface` so there is
less confusion.
The settings file will contain an override for the default snippet
interface, in addition to the default page interface, so we're renaming
it up front here.
Fixes torchbox#386

API clients could use a field on snippet objects to determine the type
of snippet they are looking at. Therefore, we change the snippet type to
an interface, similar to the page interface, so it can expose a new
field called `snippetType`.
Copy link
Member

@zerolab zerolab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few notes and thoughts in passing

docs/general-usage/interfaces.rst Outdated Show resolved Hide resolved
grapple/types/interfaces.py Show resolved Hide resolved
grapple/types/streamfield.py Show resolved Hide resolved
@@ -0,0 +1,126 @@
# Generated by Django 5.0.9 on 2024-09-20 07:17
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note to self: regenerate migrations so we're back to just the initial one

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I can do that in this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've folded migration 0003 into 0001, though I'm now wondering why it was generated, and why the wagtail.fields.StreamField constructor arguments have changed.

@mgax mgax requested review from zerolab and jams2 September 23, 2024 13:21
(
"heading",
wagtail.blocks.CharBlock(form_classname="full title"),
("heading", 0),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like the Wagtail 6.2 changes - https://docs.wagtail.org/en/latest/releases/6.2.html#compact-streamfield-representation-for-migrations

What version did you run the migrations with? It doesn't matter as such because they are more logical representations, and we don't do anything with SF migration

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I've generated them with Wagtail 6.2. But the test matrix is passing, so it looks like older Wagtail versions can still read them.

Copy link
Member

@zerolab zerolab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if @jams2 is happy with it, I am happy

let's follow up with the checks on the custom interfaces as inheriting from ours

@jams2
Copy link
Contributor

jams2 commented Sep 24, 2024

Nice work, the changes make sense to me. I think it would be nice to have some tests for:

  • when there are no registered snippet classes; and
  • there are more than one registered snippet classes

to make sure there are no surprises there.

@mgax
Copy link
Member Author

mgax commented Sep 24, 2024

Nice work, the changes make sense to me. I think it would be nice to have some tests for:

  • when there are no registered snippet classes; and
  • there are more than one registered snippet classes

to make sure there are no surprises there.

@jams2 I've added a test which stubs out the registered snippets, to test the scenario when there are no registered snippets. The test app already has two snippet types, and I've updated the initial test, to include one snippet of each type, to make sure they get returned in the same result set with no issues.

@jams2
Copy link
Contributor

jams2 commented Sep 24, 2024

@mgax looks good, thanks.

@zerolab zerolab merged commit 82717eb into torchbox:main Sep 24, 2024
16 checks passed
@mgax mgax deleted the feature/snippet-interface branch September 24, 2024 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Snippets don't identify themselves
3 participants