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

Adding server.inspect to list decorated framework interfaces #3409

Merged
merged 3 commits into from May 30, 2017
Merged

Adding server.inspect to list decorated framework interfaces #3409

merged 3 commits into from May 30, 2017

Conversation

@gordysc
Copy link
Contributor

@gordysc gordysc commented Dec 17, 2016

Addresses enhancement request: #3408

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Dec 17, 2016

I prefer this was much simpler. server.decorations as a property. Since you cannot un-decorate, keeping such a public property up to date should be trivial.

@gordysc
Copy link
Contributor Author

@gordysc gordysc commented Dec 17, 2016

Agreed, will revisit this approach.

@gordysc
Copy link
Contributor Author

@gordysc gordysc commented Dec 17, 2016

@hueniverse just for clarification, are you suggesting:

server.decorations
request.decorations
reply.decorations

Or

server.decorations = {
  server: <decorations>,
  request: <decorations>,
  reply: <decorations>
}

@devinivy
Copy link
Member

@devinivy devinivy commented Dec 17, 2016

The latter makes more sense to me.

@AdriVanHoudt
Copy link
Contributor

@AdriVanHoudt AdriVanHoudt commented Dec 17, 2016

@devinivy any particular reason why?

@devinivy
Copy link
Member

@devinivy devinivy commented Dec 17, 2016

Yes– it's hard to get a hold of a request object or reply interface simply to check if they're decorated with a specific method. Decorations are (probably!) added at plugin registration time, so I think they should be able to be introspected at plugin registration time as well.

@AdriVanHoudt
Copy link
Contributor

@AdriVanHoudt AdriVanHoudt commented Dec 17, 2016

Ok I agree. Why not both? if you want to check on request you'd have to go request.server.decorations.request[] :P

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Dec 17, 2016

Just server.decorations.

@devinivy
Copy link
Member

@devinivy devinivy commented Dec 17, 2016

@AdriVanHoudt I would omit that for the express purpose of keeping the features of the API independent of each other. Plus, if you already have a request object you can just check for the decorated method directly on it!

@gordysc
Copy link
Contributor Author

@gordysc gordysc commented Dec 19, 2016

@hueniverse is this approach more inline?

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Dec 20, 2016

I'll review it in a week or two.

@hueniverse hueniverse self-assigned this May 30, 2017
@hueniverse hueniverse added this to the 16.2.1 milestone May 30, 2017
@hueniverse hueniverse merged commit 241d7b0 into hapijs:master May 30, 2017
2 checks passed
hueniverse added a commit that referenced this issue May 30, 2017
@lock
Copy link

@lock lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants