Plating Decorator #118
Plating Decorator #118
Conversation
Current coverage is 95.07% (diff: 100%)
|
This will allow us to know the difference between a method that just applies plating and a method that does content negotitaion in the future, since the @routed version will know that it unambiguously gets a 'request'.
proper Accept-header based version should happen too, but this version is simpler and we want it for browser-based inspection anyway
we want to be able to call straight through to these methods to assert about their results with a minimum of HTTP shenanigans for easy testing. while no new code is required to implement it, verify this important property.
and it gets in the way of the flat renderer / slot namespace we're trying to set up
|
(I still have some docs in the works to go with the example but I don't anticipate they'll change the interface much) |
|
OK I think this is ready for a proper code review. This is at the upper end of the amount of code someone can review at a time, so I don't want to add more to it, but there are more things, that I will create tickets for, that this needs to be complete: |
I don't think we have any way to link to internal API docs yet.
|
Codecov's complaints are legit! I wonder why it wasn't reporting before. |
|
Rendered docs are here if you want to read them (RTD doesn't seem to have a PR preview?): |
| distinct content. | ||
|
|
||
| While just a little HTML might have been fine for the 90s, modern web apps | ||
| quickly - sometimes immediately - outgrow HTML though; soon you'll want some |
There was a problem hiding this comment.
"though" is redundant with "while". I think I prefer:
While just a little HTML might have been fine for the 90s, modern web apps quickly - sometimes immediately - outgrow HTML; soon...
|
@glyph so far so good! I'd like to drive this around for a few days, but I don't see a reason not to merge this now. |
Fixes #89