Skip to content

Implicit defaults for rendering formats in node .erb templates #4510

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

Closed
theseanything opened this issue May 7, 2020 · 3 comments
Closed

Comments

@theseanything
Copy link
Contributor

theseanything commented May 7, 2020

A review comment in PR #4502 discussed that different default rendering behaviours for the render_content_for method with node templates may results in confusion as to what format content should be written in.

It was suggested that we could add multiple methods e.g:

  • govspeak_content_for
  • text_content_for
  • html_content_for

to be explicit in the type of content required.

@theseanything
Copy link
Contributor Author

This implicit behaviour of different rendering default for different named (render_)content_for blocks has existed since moving to erb templates. Not sure if people have previously found it confusing. The behaviour also documented here.

Some named content must be a specific format (e.g. :title have to always be format :text) A possible issue with explicitly stating the format is that it adds a requirement for the person writing erb templates to know what the required format is for particular named section.

I feel like there's a larger issue around trying to put multiple formats in erb template and whether thats the most appropriate way of specifying content.

@theseanything theseanything changed the title Specific functions for rendering formats of content in node templates Implicit defaults of rendering formats of content in node templates May 13, 2020
@theseanything theseanything changed the title Implicit defaults of rendering formats of content in node templates Implicit defaults for rendering formats in node .erb templates May 13, 2020
@kevindew
Copy link
Member

@theseanything I've opened up a draft PR to propose an approach: #4527

Revising on my earlier suggestion I felt we didn't need the word content and could go with rather succinct text_for, html_for and govspeak_for methods, which also seems to make the language more natural.

I don't think it covers all the concerns you've had though, but hope you think of it as an improvement.

@theseanything
Copy link
Contributor Author

theseanything commented Mar 4, 2021

Closing as we've settled on text_for, html_for and govspeak_for and it's been working fine.

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

No branches or pull requests

2 participants