I'm continuing my experiments with falcor and enjoying most of it, but I'm noticing something concerning.
I'm assembling my JSONGraph from multiple disparate APIs, exactly what falcor-router is intended to do. However I can't seem to find a way to cleanly provide a catch-all for fields that don't need special handling w/o blowing up any routes that do need to do special handling.
My routes look something like the following:
items[{integers:ids}].name
items[{integers:ids}][{keys:fields}]
No matter the order I declare the routes in the generic one always wins. Is there a better way to avoid this than the full-nuclear option of structuring my routes like this?
items[{integers:ids}].name
items[{integers:ids}]['fooga', 'wooga', 'booga', 'tooga', ... ]
That seems very brittle, if the data coming from the backing server changes I have to update not only my application code but my router as well. It also becomes a real mess if you have deeply nested objects as the number of permutations climb in a hurry.
I believe this is a bug. The router should match the most specific path first. I would appreciate if you could log it as an issue. We will fix it for you.
Related
Simple question, in terms of best practice is it better to format my URL like this:
http://www.example.com/search?query=hello&page=1
or like this:
http://www.example.com/search/hello/page/1
Can you provide a valid reason for your choice please.
First one fits the situation where you want to "filter" your result if it gets a little too complicated, like this example:
cars.com/audi/sedan/a/4/black/manual.....
this is gonna take so long and complicated and result will be nightmare, but this would work better:
cars.com/mercedes/amg?color=white&transmission=manual
2nd way is just like thinking it of a 'folder'ed structure:
socialmedia.com/shares/1/comments/1/page/2
I am pretty sure you get the idea.
p.s. if you will provide your API to a brand new clients, who don't know anything about it, then first one is also more understandable but, i suggest you also have a API documentation which describes the parameters and the relevant poasible other calls as well. in this way your url formatting will be clearer and clients will not struggle to solve parameters in the url.
The first way is not only functional, but lets a human understand what the name/value pairs are. Sure you could go into configuration and string manipulation and make your URL look like the second example and still function, but from a readability pov and ease of function, the first one is best.
I'm learning how to do routing in MVC. It seems to me that the routing API only solves half the problem. I can easily see how to map incoming URLs to controller actions and params. However, it is not obvious to me how to generate these routed URLs in the source code of my pages.
For example, in one of my views, I use this code to get the route URL:
<a class="listingResult" href="#Url.RouteUrl("ListingSEO", new { id = Model.Listing.ID, seoName = ListingController.SeoName(Model.Listing.Title) })">
This seems like poor coding practice to me for several reasons:
If the route changes in the future, I may have many places in my View code that will need updating.
The View now requires knowledge of the ListingController (maybe this is not a big deal?)
I've lost strong typing on my input params, and if I misspell the param names, my code is broken, but this doesn't generate compile warnings.
How do I observe good coding standards when I am generating route URLs? The alternative seems to be putting static functions in the controller to generate routes, which would at least address concerns #1 and #3. If I worked with you and you saw the code above, how unhappy would you be?
My recommendations:
Generate URLs in the ViewModel, not the View: This will keep your views cleaner and logic free. You can pass the UrlHelper instance from the controller to the ViewModel, which will also help for my next point...
Use a strongly-typed URL generation technique: Such as delegate-based, expression-based or code generation.
One of the purposes of using named routes is to abstract the controller/action. Your named routes shouldn't really change. At the most, you'd just change the controller/action they hit, but that happens seamlessly behind the scenes because you're using named routes.
Your view requires knowledge of the controller because you've added a dependency on it. This is bad for a number of reasons. There's many different ways you could handle this that wouldn't require a dependency on the controller, depending on what it is you're actually doing here, but at the very least, you should simply use a utility class, so at least it wouldn't be controller-specific.
The route params are intentionally not strongly-typed, because routes are flexible by design. You can pass anything you want to the action, with or without a parameter to catch it (you can use something like Request to get at it without a param).
I have the following call:
http://localhost:3000/arc/v1/api/menus/51/only_items_with_notes
and I'm curious what is the preferred structure of the url - This reads fine and is totally clear what it means. But I am not sure if this is the canonical way to do this. One issue is that it does proliferate the routes.rb file. I have:
get '/menus/:menu_id/only_items_with_notes' => 'api_menus#only_items_with_notes'
One think I don't like is that it reads a bit like a pseudo nested attribute. What is the proper, canonical way to do this?
That’s pretty deep nesting. What other routes do you have?
In the absence of more information, I’d suggest that only_items_with_notes is really a filter on the functionality of the index action. You can use a query parameter to restrict the items to those with notes.
I know this question has been asked many times. But people suggest creating custom derived route classes, or writing lowercase everywhere in code (for action links) which is a really dirty way (what if I just decide to make'em all Pascal Cased again? changing hundreds of links?), or they suggest to create HTML helpers to do that (which is not a bad answer). But isn't there a more simple way? I mean something like setting some configuration in web.config file, or using an HttpModule or something else which is both simple, and centralized?
Apart from the options you have already listed, I can think of no other way of producing this result.
In short, the URL needs to be processed by 'something', be it .ToLower(), a Helper Method or HTTPModule.
In most of our applications, we use a Global Static method that performs actions on the desired URI and returns the result.
The following will allow that.. http://mvccoderouting.codeplex.com/ - and much more besides.
I am trying to write a route that matches the following URL format:
/category1/category2/S/
where the number of categories is unknown, so there could be 1 category or there could be 10 (1..N).
I cannot use a catch all becuase the categories are not at the end of the URL.
I am actually routing to a web form here (using Phil Haack's example http://haacked.com/archive/2008/03/11/using-routing-with-webforms.aspx), but that is beside the point really.
Any ideas?
To be honest, I found the answer here to be more useful: Using the greedy route parameter in the middle of a route definition
The blog post linked to in the question was extremely useful: http://www.thecodejunkie.com/2008/11/supporting-complex-route-patterns-with.html
I think it's impossible but you could try work around it using this route:
{categories}/S
Then split the categories using the '/' character yourself.
I made a site where I just fixed it to 1-3 categories by registering 3 routes, but I had to work around a lot of things and wasn't really happy with it afterwards.
EDIT: Using S/{*categories} will catch the categories. You can only use it at the end of the URL.
Exactly what you need(ed)
This is a long time lost shot, but I seem to have exactly what you need. I've written a GreedyRoute class that allows greedy segment anywhere in the URL (at the beginning, in the middle or at the end - which is already supported).
You can read all details on my blog as well as getting the code of this particular class.
The main thing is it supports any of these patterns:
{segment}/{segment}/{*segment}
{segment}/{*segment}/{segment}
{*segment}/{segment}/{segment}
It doesn't support multiple greedy segments though (which is of course possible as well but has some restrictions that should be obeyed in that scenario), but I guess that's a rare example where that could be used.