Fix adapter registration #368
Conversation
And it needs to be registered in ZCML to get a name.
|
@gforcada thanks for creating this Pull Request and helping to improve Plone! TL;DR: Finish pushing changes, pass all other checks, then paste a comment: To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically. Happy hacking! |
|
maybe the docs should be fixed then? |
|
Oh, nice, I thought there were no docs, I did not even do a search (my laziness, sorry 🤚🏾 ). But to me the docs look fine 🤔 but the ZCA is still a bit of a mystery for me 😓 |
I was trying to add some extra classes on the
<body>and I expected to be an adapter to extend the functionality, and indeed, there it was:plone.app.layout.globals.interfaces.IBodyClassAdapter✨Even better, there is already an example adapter on
plone.app.layout.globals.layout.DefaultBodyClasses🤩There is one catch though, the adapter is not registered in ZCML (so that it gets a name) and is actually a multi adapter (context, request), but it was only registered as a single adapter.
Anyway, long story short: here is a fix for it 🎉
I'm wondering if it would make sense to already split the
LayoutPolicy(also inp.a.l.g.layout) and create smaller adapters? 🤔Anyway, meanwhile we can fix the actual code, so anyone else wanting to add some extra classes on the
<body>class does not have to try to figure out how that works 😄