Make ActionFilter for simple filtering required by spec

[SphtKr]

Per section "Filtering", simple value filtering should be possible via the query string. Seems the place to add this would be via an ActionFilterAttribute subclass that could be used to decorate ApiController::Get() @csantero says he already has a basic implementation that may be adaptable here. See discussion in #7.

Suggest that in addition to single values, we also support comma-separated values--this should be easy and cheap to implement.

[csantero]

I'll try to whip up a PR for this today.

To clarify, when you mention comma-separated values, you're saying that the following query:

GET http://localhost/posts?title=foo,bar

should return posts whose title is either foo or bar? What about values that have a comma in them? Seems like that would need to be double-encoded. Would this be better instead?

GET http://localhost/posts?title=foo&title=bar

As an aside, is ember-data capable of performing queries in this manner?

[SphtKr]

Right, that's it, an "or" operation. The thought process is that I was wondering if we could leverage the same or similar ActionFilter to handle multiple-ID selection, which is like /posts/1,2,3. Right now that logic is in ApiController::Get(string id), and it makes it hard to override that method without losing the multiple-ID request feature--so I wondered if an ActionFilter on ApiController::Get() would be the way to go there as well.

FWIW, I think older versions of Ember Data actually did multiple id resolution as ids=1,2,3 by default. As for right now, while I don't think Ember Data will automatically do this for any reason, you can use fetchQuery and pass whatever parameters you want. And, off the top of my head, I'm not sure if you can make that mechanism issue the ?title=foo&title=bar format, since you mentioned it (maybe, if you pass title: ['foo','bar']?).

One use-case I had in mind was enums, for instance I have a ticket system with six severities for tickets, 0-5, where 0 is used for dismissed tickets. Right now, to show active tickets, I use an OData query for severity != 0...but I could do severity=1,2,3,4,5 to achieve the same result.

Commas in the value is a very good point. I asked the question about the escaping mechanism for the spec itself in an issue something like a year ago, which is not a simple issue because you can't just URLEncode it! I'll go dig that up because I don't remember what the answer was. The context then was what about IDs with commas in them (e.g. coordinates), and now the spec says that IDs SHOULD only contain alphanumerics, hyphens and underscores...but I suppose that means the question still remains.

On Jan 20, 2015, at 4:38 PM, Chris Santero notifications@github.com wrote:

I'll try to whip up a PR for this today.

To clarify, when you mention comma-separated values, you're saying that the following query:

GET http://localhost/posts?title=foo,bar
should return posts whose title is either foo or bar? What about values that have a comma in them? Seems like that would need to be double-encoded. Would this be better instead?

GET http://localhost/posts?title=foo&title=bar
As an aside, is ember-data capable of performing queries in this manner?

—
Reply to this email directly or view it on GitHub.

[csantero]

I'd definitely like this feature too, but for now I think the most important thing is to get single-value filtering in. We can revisit OR-matching in a later PR.

[SphtKr]

Okay, I researched the comma-escaping question...it was never answered. I've asked to reopen my original issue WRT commas in the ID from nearly two years ago because it still isn't actually answered.

That said, while I was thinking about it, I've unfortunately decided that supporting comma-separated query values is probably a bad idea. Consider your question about what if a value has a comma in it? Well, if it does, and the user is querying for multiple values, fine, we need some rule for them to escape the comma--since we're going above and beyond the spec that's reasonable. However, if they query for only the single value, we would require them to escape the comma in that situation too...which makes us non-compliant with the spec because the unescaped comma is a valid request.

So unfortunately, I probably just need to wait to solve #15 for this use case. I'll strike it from the issue.

[csantero]

@SphtKr I think we can close this, right?

[SphtKr]

Was leaving it open to see if we could add support for filtering on object IDs after the ModelManager refactor. Now it should be easy to derive the Id property from within the action filer and add it to the linq expression, right?

[csantero]

Yeah, but now we have to get the ModelManager into the attribute instance. We can do this easily if you're adding the attributes programmatically, like so:

var pluralizationService = new PluralizationService();
var modelManager = new ModelManager(pluralizationService);

var formatter = new JsonApiFormatter(pluralizationService);
config.Formatters.Clear();
config.Formatters.Add(formatter);

config.Filters.Add(new EnableFilteringAttribute(modelManager));

but I think this makes it impossible to add the attribute directly to an action method. Do we care?

[csantero]

Actually I think IFilterProvider is what we want here. I'll look more into that.

[SphtKr]

Wait, I thought you already had a reference to the Formatter available in OnActionExecuted? Is that not the same formatter? If it is you can just access it's ModelManager property.

[SphtKr]

Speaking of which, I need access to ModelManager from within MetadataManager to do the conditional relationship serialization, so if we need to make it more generally accessible somehow, that might be good.