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

Support delimited list parameters #66

Closed
jmcarp opened this issue Sep 29, 2015 · 3 comments

Comments

@jmcarp
Copy link
Contributor

commented Sep 29, 2015

Currently, webargs supports list parameters in query strings using repeated parameters: foo=bar&foo=baz. But it's also a common pattern to encode lists in query strings using delimited values: foo=bar,baz, foo=bar|baz, etc. This is described using the collectionFormat in swagger: https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#fixed-fields-8. It would be helpful to expose control over the formatting of list values to support both repeated and delimited parameters.

Here are a few thoughts about interfaces:

  • Use a subclass of List, like DelimitedList, that splits and joins on a delimiter on de/serializing.
  • Add an optional delimiter argument to List that has the same behavior as above.
  • Add an option to Schema.Meta that controls de/serialization of lists:
class ArgSchema(Schema):
    class Meta:
        list_delimiter = ','

Not sure if I like any of these. What do you think @sloria?

@sloria

This comment has been minimized.

Copy link
Member

commented Sep 29, 2015

The 1st option seems best. List is not meant to deserialize from strings, so that rules out 2. Option 3 doesn't seem ideal because you wouldn't be able to use the feature with dictionary argmaps.

@jmcarp

This comment has been minimized.

Copy link
Contributor Author

commented Sep 29, 2015

Agreed with everything you said, but the first option strikes me as a little underpowered. In most use cases, all list parameters for a given resource will be encoded in the same way (all repeated parameters, or all delimited parameters), so I still like a higher-level option--what about an argument passed to parse and use_(kw)args? That said, I still think the lower-level option is independently useful, so I'm down to take a pass at it.

By the way, I don't particularly like delimited query parameters, but they seem to be pretty commonly used, and are even recommended by JSON-API, which is why I'd like to add support.

@sloria

This comment has been minimized.

Copy link
Member

commented Sep 30, 2015

Good point. I want to avoid adding a custom Schema class in webargs for the time being. Would it be enough if the delimiter option were configurable at the Field class level and as a constructor argument?

@jmcarp jmcarp referenced this issue Sep 30, 2015

@sloria sloria closed this in 8fe5ece Oct 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.