This project is read-only.

Strongly typed URLs?

May 29, 2009 at 3:13 AM

One of the great strengths of a URL based system such as nRoute is the flexibility afforded by it, loose coupling, etc.

However, this also potentially comes with a significant down-side: No compile-time checking of URLs.

In a similar area that usually requires the use of strings, notfiication of dependency properly changes, you used lambda expressions in a recent blog to provide strong typing.

With attributes this won't work afaik since it can only take constant expressions.

I can think offhand of two approaches:
1. Define a constant class (or possibly more than one) that lists all URLs and refer to these both in all attributes as well via StaticResource in XAML.
2. Provide some parsing tool that retrieves all URLs (both providers and users) and check for any mismatches

Are there other approaches? Any comments on the approaches above?

May 29, 2009 at 2:58 PM

This is a very interesting question, strongly-typed Urls are potentially very useful but its not something I’ve really thought about seriously. But from what I know, strongly-typed Urls have been tried in ASP.NET, however I don’t think they have been particularly successful. In one such attempt I remember, someone made use of the Custom Expressions facilities available to ASP.NET - which maybe we can re-attempt using TypeConverters in XAML. And the type-converters can possibly check the Urls at runtime and raise an exception for unknown Urls.

Now, things like static resources are not checked at either runtime or compile time, so I am not sure if they will be helpful. All the same, I think playing nice in XAML would be a big requirement for any strongly-typed Urls solution. One idea which I’ve thought about before is using a XML based file that enlists all the routings. Now, if we could convert the XML-based listing to some type of “settings” like properties that could be interesting.

Also, the parsing thing is interesting because we can check the Urls against the routes table, but that is only at runtime. Maybe by using the XML file thing we can come up with a neat tool, but I need to mull over the idea. So, let me leave at this but I’ll try different things and let you know very soon.

One last thing, I was considering putting a prefix in Urls so something like nav://View/Contacts for Navigation and acn://View/Contacts/RefreshAll/ for use with actions. But I’ve not really validated this idea, but the point was to have a unified approach in xaml for triggering Urls based Navigation, Actions or whatever. I don’t know if see value in such prefixes.

May 29, 2009 at 3:15 PM

Thanks for the quick response.

I definitely like the idea of having all routing information available centrally, whether XML or otherwise.

Scott Guthrie's article on ASP.NET MVC routing (http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc-framework-part-2-url-routing.aspx), which I understand was the starting point for nRoute, shows how to unit test the routes. I am definitely a fan of finding out problems before QA or customers find them, and mistyping a URL is definitely an error that I see will be easily made.

Whether it is detected via compiler, static code analysis, unit testing or automated integration testing (as long as the effort involved is not too great) is secondary to being able to do so.

On the prefix idea: I too wouldn't go with prefixes. In HTML you can have addresses in URL form (http:... ) and mailto addresses (i.e. different prefixes), but you share the same HTML element (the <A> tag). In nRoute however we already indicate the type of action (navigation, action, command) based on the tag. Repeating this information in form of a prefix feels redundant.