The controller does not filter the data in the Breeze request in the DotNetNuke module

Question

I am trying to include a basic Breeze sample in the DotNetNuke module (it works fine in a standalone WebAPI project). To simplify things, I delete the client and simply refer to the JSON URL calls that I make in the Chrome browser.

I see my metadata and a complete list of elements, for example: http://www.dnndev.me/DesktopModules/framework/api/breeze/dare/metadata http://www.dnndev.me/DesktopModules/framework/api/breeze/ dare / todos

however, when I try to filter a list from a URL, it always returns a complete list, for example. http://www.dnndev.me/DesktopModules/framework/api/breeze/dare/todos?=DareId%20eq%204

I think this is due to the way I declared MapHTTRoute. The problem is that DotNetNuke modules do not have Global.ascx. I copied the BreezeWebApiconfig.cs file to the App_Start folder, and this works when debugging, however DotNetNuke uses a mechanism to register routes:

using DotNetNuke.Web.Api; namespace SmartThinker.Modules.Framework { public class RouteMapper : IServiceRouteMapper { public void RegisterRoutes(IMapRoute mapRouteManager) { mapRouteManager.MapHttpRoute("framework", "BreezeApi", "breeze/{controller}/{action}", new[] { "SmartThinker.Modules.Framework.Controllers" }); } } } 

I read http://www.breezejs.com/documentation/web-api-controller#note01 and http://www.breezejs.com/documentation/web-api-routing , but it seems to be related to how DNN records routes. Is there a way to do this without using BreezeWebApiConfig.cs?

My controller code has a BreezeController attribute. (When I connect a client sample to it, I get a list of elements - it just does not filter, so I think it is something with OData action filters. How can I debug where the problem is?

Update 1) Here is the metadata: http://www.ftter.com/desktopmodules/framework/api/dare/metadata

GetUsers Method: http://www.ftter.com/desktopmodules/framework/api/dare/getusers

and the GetUsers method trying to filter by UserID (which does not work, which is the problem) http://www.ftter.com/desktopmodules/framework/api/dare/getusers?=UserID%20eq%204 http: //www.ftter .com / desktopmodules / framework / api / dare / GetUsersWithoutCors? = UserID% 20eq% 204 (this returns IQueryable)

Here is the controller:

 [BreezeController] public class DareController : DnnApiController { private readonly EFContextProvider<FrameworkContext> contextProvider = new EFContextProvider<FrameworkContext>(); [AllowAnonymous] [HttpGet] public HttpResponseMessage Metadata() { var response = Request.CreateResponse(HttpStatusCode.OK, contextProvider.Metadata()); return GetResponseWithCorsHeader(response); } [AllowAnonymous] [HttpGet] public HttpResponseMessage GetUsers() { var userInfoController = new UserInfoController(); var response = Request.CreateResponse(HttpStatusCode.OK, userInfoController.GetUsers()); return GetResponseWithCorsHeader(response); } [AllowAnonymous] [HttpGet] public IQueryable<User> GetUsersWithoutCors() { return contextProvider.Context.Users; } } 

Answer 1

Routing is not a Breeze problem. How your server sends requests to your controller is up to you. What we do out of the box is just one way among countless many.

Do you have the [BreezeController] attribute on your controller? Can you put the end point of the sample where we could hit it. Could get some tips from this. Also put the controller. A tiny example should ... return metadata and one method that returns IQueryable.

June 25, 2013 Patch

I think you found an error in how our [BreezeController] detects methods that return an IQueryable<T> .

The [BreezeController] attribute scans your web API control methods and (in effect) applies the [BreezeQueryable] attribute to methods that return IQueryable<T> .

[BreezeQueryable] is a [Queryable] web API extension that adds support for $ select, $ expand and nested $ orderby ... all missing in the current [Queryable] .

Now I see that your GetUsers() method returns an HttpResponseMessage , not an IQueryable<User> . Suppose the userInfoController.GetUsers() method inside your method returns an IQueryable<User> . Otherwise, the OData query parameters will not be applied, and we will have to take this in a different direction. We move forward ...

I checked with v.1.3.6 Breeze.WebApi.dll and did not find that HttpResponseMessage is an IQueryable<T> wrapper. Therefore, it does not apply OData client request criteria (or any other OData modifiers, for that matter). This flaw (in my opinion) is a mistake. The following should be equivalent implementations:

 [HttpGet] public IQueryable<TodoItem> Todos() { return _repository.Todos; } [HttpGet] public HttpResponseMessage TodosWrapped() { return Request.CreateResponse(HttpStatusCode.OK, _repository.Todos); } 

The second wrapped method does not consider OData query parameters.

Fortunately, there is a workaround until we fix this. Just add the [BreezeQueryable] attribute explicitly ... as in:

 [HttpGet] [BreezeQueryable] public HttpResponseMessage TodosWrapped() { return Request.CreateResponse(HttpStatusCode.OK, _repository.Todos); } 

I have confirmed that this approach works .

Thanks for finding this.

Use OData query syntax h3>

A colleague also noticed that your request URL does not use OData request syntax. You wrote:

  ... / todos? = DareId% 20eq% 204

when should he be

  ... / todos /? $ filter = DareId% 20eq% 204

Make sure you use ?$filter=