multiple request.args should reach the endpoint (?a=1&a=2 => a=[1,2])

[llonchj]

When calling something like /delete/project?version=1&version=2, version parameter is 1 and 2 is omitted.

@route("/<pk>", Http.DELETE)
def delete(self, request, pk, version=None, **kwargs):
    #version is 1 and should be a [1, 2]
    pass

Does this make any sense?

I have fixed this in llonchj/corepost@bee483e but need some help with the freshen tests. Please, can you write one for me?

P.S. I will pull request the branch when tests are written

[jacek99]

I would disagree with this. Instead of checking for a single value now anywhere you can get a list. I would say the proper behavior would be to just take the last value (2) and ignore the first one instead.

what do you think?

[llonchj]

Multiple parameters are accepted by the majority of the RESTful libraries.
It is part of the standard and the accepted behavior.

2013/4/25 Jacek Furmankiewicz notifications@github.com

I would disagree with this. Instead of checking for a single value now
anywhere you can get a list. I would say the proper behavior would be to
just take the last value (2) and ignore the first one instead.

what do you think?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-16944170
.

[jacek99]

OK, but does that mean that now everywhere in your code you need to do a "is parameter a list" check?
I can't say I like it. All the user has to do is send multiple params into a method that does not support it and get a 500 error as a result.

JAX-RS in the Java world does not support this for example.

Maybe a better option would be to explicitly mark which parameters can be a list and in that case we would ALWAYS pass them as a list (e.g. [1],[2],[1,2]) for consistency?

[llonchj]

But on the other side, Twisted's request.args or python cgi.parse return lists. Not that I am saying corepost should keep every single parameter as a list (like python/twisted), but, when multiple arguments are present in the URL, information should not be missed.

Yes, I will love a schema (like in django-tastypie).

[jacek99]

could you point me to a good resource on django tastypie schemas? I always like to pinch from the best :-)

[llonchj]

I think the tastypie schema will be hard to implement in CorePost because
of the design. But here's the resources:
https://django-tastypie.readthedocs.org/en/latest/interacting.html?highlight=schema#inspecting-the-resource-s-schema

Thanks!

2013/4/25 Jacek Furmankiewicz notifications@github.com

could you point me to a good resource on django tastypie schemas? I always
like to pinch from the best :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-16946339
.