Support ad-hoc query params about rocket HOT 16 CLOSED

@kestred The reason I'd like to use different syntax here is to differentiate between the arity of the collection. I propose that <...> is always 1-ary, as it is now, while {...} is used for n-ary collections of parameters. Thus, {param1, param2} is valid while <param1, param2> is not.

from rocket.

Will wait to see if others would like this as well. I generally don't use query strings, so this is low in my personal bucket-list.

from rocket.

Definitely a desirable feature, doing parsing with structs is obviously cleaner in a lot of cases, but for quick prototyping of methods this would be invaluable.

from rocket.

I'd like to have such feature because it is very useful. e.g. in my current project we use pagination as query params like perPage and currentPage so it'd be nice to avoid creating 2 struct and just use primitive.

from rocket.

I would find this feature helpful; I actually expected it to work this way after switching from a path parameter (like #[post(/<blah>")] fn blah(blah: String) to a query parameter #[post(/?<blah>")] fn blah(blah: String).

I notice you recommended using syntax {blah} for plain params vs <blah>, however I would expect that the latter would have worked with anything implementing FromParam.

Possibly there could be multiple varieties (like <var> for FromParam, {var} for FromData, and [var] for FromForm) but I don't like that solution too much because the syntax would feel somewhat arbitrary?

from rocket.

This would certainly be useful. It would also be nice of the param could be converted from camel case to snake case automatically during this process.

So ex, a param comes in as MyParam but you specify fn(my_param: String). (Ex, twilio uses camel case when it submits a request)

from rocket.

Does this also imply that it is not possible to have one function handle URLs with and without a query string?

I have
#[post("/events?<query>", data = "<events>")]

But even though the struct that query goes into is just an Option<String>, it won't match /events

from rocket.

@SergioBenitez Would consider support multi query params ? #[get("/hello?<p1><p2>")] or #[get("/hello?{<p1>, <p2>}")]

from rocket.

@sickHamm Imagine both struct p1 and p2 both having a field of the same name. Who gets the value? Do they both? Suppose Rocket could check at compile time to make sure structs p1 and p2 wouldn't conflict.

from rocket.

@sickHamm How does that differ from what's being proposed here via path?{p1, p2}?

from rocket.

@sickHamm Doesn't. :D

from rocket.

@SergioBenitez

while {...} is used for n-ary collections of parameters. Thus, {param1, param2} is valid

struct  P1 { ...};
struct P2 {...};
#[get("/hello?{p1,p2}")]
fn hello(p1: P1, p2: P2)

is valid?

In my opinion {p1, p2} mean p1, p2 both "simple" type that impl FromFormValue;
{<p1>, <p2>} mean <p> is ”complex” type must impl FromForm.

from rocket.

if <> just mean 1-ary collections and {} is used for n-ary collections ; what differ {p1} via <p1> ,
and above example should be valid， so just a simple usage would have many problem as @lholden say;

from rocket.

Accepting this and slating it for 0.5.

from rocket.

Accepted for 0.4. Tracked in #608 as part of the new query-string handling.

from rocket.

It is not invalid to have the same param name appear multiple times in a query string "arg=1&arg=2"
How is this handled?
Also re how that interrelates to params passed in the body - what does the spec say? is the spec is silent then what do other frameworks do?

from rocket.