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

Provide ability to restrict declared(params) to local endpoint #530

Closed
wants to merge 1 commit into from
Closed

Provide ability to restrict declared(params) to local endpoint #530

wants to merge 1 commit into from

Conversation

myitcv
Copy link
Contributor

@myitcv myitcv commented Dec 9, 2013

#503 (which has been pulled) changes the default behaviour of declared(params) to return all params from the current endpoint and containing namespaces.

This PR provides the ability to restrict that to the local endpoint (effectively the previous default behaviour) via an option:

declared(params, restrict_local: true)

This is particularly useful for endpoints which create/update resources.

I think the current default (i.e. with #503 pulled) is correct. i.e. one should have to specify restrict_local to only consider params defined on the local/current endpoint, hence this PR. Arguably the ability to restrict should have been included in #503.

Thoughts?

I can updated the CHANGELOG if we are comfortable.

@dblock
Copy link
Member

dblock commented Dec 10, 2013

To keep a positive spirit,... okay, to keep things consistent with other options, I'd like that option to be a positive one. Instead of restrict_local I would make it include_some-good-name-here and default that to true.

@myitcv
Copy link
Contributor Author

myitcv commented Dec 10, 2013

Quite understand the desire for consistency. How about:

declared(params, include_parent_namespaces: true)

Thinking being that 'parent' is more descriptive than 'containing'

include_parent_namespaces would be true by default, hence retaining the behaviour as committed in #503

Thoughts?

@dblock
Copy link
Member

dblock commented Dec 10, 2013

Are there any other kinds of namespaces? Otherwise maybe just include_namespaces? Otherwise yes.

@myitcv
Copy link
Contributor Author

myitcv commented Dec 10, 2013

The only potential confusion is with namespace's which are defined in the same namespace as the calling endpoint: e.g

class MyAPI < Grape::API
  params do
    requires :id, type: String
  end
  namespace ':id' do

    params do
      requires :name, type: String
    end
    get do
      # ** CALL FROM HERE **
      declared(params)....
    end

    params do
      requires :age, type: Integer
    end
    namespace ':age' do

      # ...

    end
  end
end

Hence 'parent' captures every namespace that contains the current endpoint.

@dblock
Copy link
Member

dblock commented Dec 12, 2013

That makes sense. I'll take a PR with whichever.

@myitcv
Copy link
Contributor Author

myitcv commented Dec 16, 2013

Ok, I've updated the commit to use include_parent_namespaces - this includes some further documentation changes to explain things a bit further.

Let me know if there's any further clarifications I can make

@myitcv
Copy link
Contributor Author

myitcv commented Jan 3, 2014

@dblock - any update on this?

@dblock
Copy link
Member

dblock commented Jan 3, 2014

This looks good. Can you amend with a CHANGELOG entry, please? Thx.

@myitcv
Copy link
Contributor Author

myitcv commented Jan 3, 2014

All done

expect(json[:declared_params].keys).to match_array [:foo, :bar, :id]
end

it 'should not include params defined in the parent namespace with include_parent_namespaces: false' do
Copy link
Member

Choose a reason for hiding this comment

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

Change the text from "should not include" to "does not include".

@dblock
Copy link
Member

dblock commented Jan 3, 2014

See my minor comment in spec, and please rebase this.

@myitcv
Copy link
Contributor Author

myitcv commented Jan 3, 2014

All done (again!)

@dblock
Copy link
Member

dblock commented Jan 3, 2014

Merged via 3a55dc7 (slight change in the CHANGELOG wording).

@dblock dblock closed this Jan 3, 2014
@myitcv
Copy link
Contributor Author

myitcv commented Jan 3, 2014

Awesome. Thanks

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.

2 participants