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

Refactor ContentBlockEdition create to accepted nested document attrs #9271

Merged
merged 3 commits into from
Jul 18, 2024

Conversation

tahb
Copy link
Contributor

@tahb tahb commented Jul 16, 2024

Changes in this PR

It was becomign cumbersome to remember which attributes were for the document and which were for the edition when it came to creating and updating.

Instead of having to track this we can use the Rails accepts_nested_attributes_for to help us take care of this. The main Whitehall repository takes this approach[1].

With it we’re able to send around a single blob of params, pass them to the Edition ORM and it’ll figure out what to do, including validations.

  • We have to make one override to the title error message so we see “Title can’t be blank” rather than “Content document title can’t be blank”.
  • We also adjust the hidden field for block tag so it puts the params in the same place. Inside content_block_edition, rather than content_block_document_attributes at the top level. We’ll now have content_block_edition: { details: {}, content_block_document_attributes: {}}. This feels more conventional, what do we think?
  • In renaming these attributes we also fix the form so the error messages correctly link to the title field on error
creation.mov

@tahb tahb requested a review from pezholio July 16, 2024 15:28
@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch 2 times, most recently from 125b375 to a0d25cf Compare July 16, 2024 18:37
@pezholio
Copy link
Contributor

Looks good - I totally forgot about accepts_nested_attributes_for - the cukes seem to be failing for some reason though...

tahb added a commit that referenced this pull request Jul 18, 2024
Following a discussion[1] we want to clarify what we expect this concern to contain.

We want this to be more than identification, we want it to be everything that connects an edition to a document.

This does diverge us from the main Whitehall we were referencing which may make this harder to merge back together later. But for now the short term benefit of the team knowing how to use it clearly takes priority.

[1] #9271 (review)
@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch from a0d25cf to d45cf66 Compare July 18, 2024 13:24
@tahb
Copy link
Contributor Author

tahb commented Jul 18, 2024

Okay folks after looking at that cucumber test I had to work on customising the error messages. That's now done with help from @pezholio ❤️

Whilst I look at this rebase it's ready for another review please. I'm conscious the longer this type of change stays in progress the many more conflicts we'll get.

cc @Harriethw

@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch from d45cf66 to ad57e4f Compare July 18, 2024 13:28
tahb added a commit that referenced this pull request Jul 18, 2024
Following a discussion[1] we want to clarify what we expect this concern to contain.

We want this to be more than identification, we want it to be everything that connects an edition to a document.

This does diverge us from the main Whitehall we were referencing which may make this harder to merge back together later. But for now the short term benefit of the team knowing how to use it clearly takes priority.

[1] #9271 (review)
@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch 3 times, most recently from d17d3f1 to acb4d12 Compare July 18, 2024 13:38
tahb added 2 commits July 18, 2024 14:38
We’ll use this next with custom error messages.
Following a discussion[1] we want to clarify what we expect this concern to contain.

We want this to be more than identification, we want it to be everything that connects an edition to a document.

This does diverge us from the main Whitehall we were referencing which may make this harder to merge back together later. But for now the short term benefit of the team knowing how to use it clearly takes priority.

[1] #9271 (review)
@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch 2 times, most recently from d02b545 to 974078c Compare July 18, 2024 14:10
It was becomign cumbersome to remember which attributes were for the document and which were for the edition when it came to creating and updating.

Instead of having to track this we can use the Rails `accepts_nested_attributes_for` to help us take care of this. The main Whitehall repository takes this approach[1].

With it we’re able to send around a single blob of params, pass them to the Edition ORM and it’ll figure out what to do, including validations.

* We have to make one override to the title error message so we see “Title can’t be blank” rather than “Content document title can’t be blank”.
* We also adjust the hidden field for block tag so it puts the params in the same place. Inside `content_block_edition`, rather than `content_block_document_attributes ` at the top level. We’ll now have `content_block_edition: { details: {}, content_block_documentattributes: {}}`.
* In renaming these attributes we also fix the form so the error messages correctly link to the title field on error

[1] https://github.com/alphagov/whitehall/blob/7cbd2b9b6d97df9741befcc4700fb573fb2e1960/app/models/edition.rb#L82]
@tahb tahb force-pushed the content-modelling/refactor-content-block-param-handling branch from 974078c to cc4a997 Compare July 18, 2024 14:12
Copy link
Contributor

@Harriethw Harriethw left a comment

Choose a reason for hiding this comment

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

think it makes sense to me...thanks for these improvements!

Copy link
Contributor

@pezholio pezholio left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@tahb tahb merged commit 9b3b586 into main Jul 18, 2024
19 checks passed
@tahb tahb deleted the content-modelling/refactor-content-block-param-handling branch July 18, 2024 14:24
@@ -1,3 +1,5 @@
en:
activerecord:
attributes:
content_object_store/content_block_edition/content_block_document:
Copy link
Contributor

Choose a reason for hiding this comment

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

would you be able to ELI5 how this is used? Is there magic going on in the view somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rails magic! Which is why it was so hard to find the right combination.

What I had to go on was this piece of the docs, if you scroll down slightly you get to this:

In the event you need to access nested attributes within a given model, you should nest these under model/attribute at the model level of your translation file:

en:
  activerecord:
    attributes:
      user/role:
        admin: "Admin"
        contributor: "Contributor"

Which gave me the clue there was some magic / syntax to make it work for nested objects.

The trouble I had was how content_object_store came into the picture, i.e why not

content_object_store/content_block_edition/content_object_store/content_block_document:
or 
content_object_store/content_block_edition/content_block_document_attributes:

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.

3 participants