URL Routing with Kentico CMS

   —   
Does Kentico CMS support URL routing? Read this article to learn more ...
Hi there,

ASP.NET 3.5 came with an interesting feature called URL Routing, we will look at what it does more closely and compare it to our Wildcard URLs.

What is the ASP.NET URL routing?

The ASP.NET routing mechanism is basically URL rewriting evolved to support handling of dynamic context specific URL by a single page. Originally, it was made only for pure MVC development model, but it extended to WebForms with .NET 4.0.

Here is some basic introduction to it: http://weblogs.asp.net/scottgu/archive/2009/10/13/url-routing-with-asp-net-4-web-forms-vs-2010-and-net-4-0-series.aspx

With WebForms URL routing, you typically define something like a lookup table in your Application_Start method, which says what URLs should be translated to which physical pages.

To register the route, you just register the page with the given "wildcard" with named parameters:

routes.MapPageRoute("products-browse", "products/{category}", "~/Products.aspx");
  • products-browse is a name of the route
  • products/{category} is the URL wildcard
  • ~/Products.aspx is the processing page
So basically if you access products/CPUs, you get to the page ~/Products.aspx and you can pull the parameter category from you context, using several ways how to access it either declaratively or functionally.

It is kinda nice if you ask me, but the need to register all my possible URL formats from App_Start? No thanks! We provide better options ...

What are Kentico CMS URL wildcards?

This may seem like a deja vu, but Kentico CMS URL wildcards is basically URL rewriting extension to support handling of dynamic context specific URL by a single page. Sounds familiar? It should ... :-)

Yes, if you look more closely at the Kentico CMS URL wildcards, you can very easily see that it is quite the same thing, yet a little different in how you use it.

With Kentico CMS, you have your /Products page in your content tree, that is your displaying context.

If you go to the document properties and set the URL path to /products/{category} (again, seems familiar?), you just defined your dynamic context URL for that page.

The route name is not needed in this case, since the context is basically the document itself.

Similar to ASP.NET routing, when the request comes to the server, it is processed by the document template (either ASPX or Portal) and your controls typically use the querystring parameter or macro to get the route parameters.

So we have basically the same settings (even with same syntax) in background, here are the differences:
  • Kentico CMS is not based on ASP.NET routing engine
  • You can find the wildcard parameter directly in your querystring and use it in macros (there is no specialized collection for it)
  • Kentico CMS routing works dynamically as you set it in the document's properties, no need to define some static routing table in App_Start.
So the conclusion is that you may use the routes very well if you use them through our wildcard URLs.

See the complete documentation on Wildcards here: http://devnet.kentico.com/docs/devguide/wildcard_urls.htm

Or watch the webinar on URL rewriting here: http://devnet.kentico.com/Blogs/Martin-Hejtmanek/December-2009/Webinar-3---URL-rewriting-and-processing-in-Kentic.aspx

Why is our implentation different?

There are several reasons why Kentico CMS isn't based on the ASP.NET routing, they are following:
  • First of all, we need it to be dynamic and directed by the document data from the database.
  • We still support ASP.NET 2.0, and routing for WebForms is available from .NET 4.0.
  • We may need to improve it even more in the future, which could be hard being bound with some other solution limitations. (we still may think about it in future, we will see)
  • The fact that the syntax we use is the same is just a fortunate coincidence :-)
What's next?

That's it, now you know you don't need to take care about ASP.NET routing, you may use our wildcard URLs instead of it with more flexibility.

See you next time ...
Share this article on   LinkedIn

Martin Hejtmanek

Hi, I am the CTO of Kentico and I will be constantly providing you the information about current development process and other interesting technical things you might want to know about Kentico.

Comments

Ashish Pandey commented on

Hi,

I was reading your article and I would like to appreciate you for making it very simple and understandable. This article gives me a basic idea of URL Routing in ASP.Net 3.5(IIS7) and it helped me a lot. Thanks for sharing with us. Check out this link too its also having nice post with wonderful explanation on URL Routing in ASP.Net 3.5(IIS7), for more details check this....

http://mindstick.com/Articles/9992a0bc-90f5-4f04-823a-31f901b61643/?URL%20Routing%20in%20ASP.Net%203.5%28IIS7%29

Thank you very much!

Martin Hejtmanek commented on

Yes, that may be the right solution. Currently, you can just exclude the URLs in settings so they are processed by your own logic.

Appetere Web Design & Web Development commented on

Just a thought about how to support different versions of .NET

Would it be possible to make more use of the provider model/pattern in future releases of Kentico?

So for URL routing, you would have a default provider that works with .NET2.0 (as now), but you would allow a different provider to be substituted (say based on Microsoft's URL rewriting engine) which may require a more recent version of .NET.

Then you maintain compatibility both with older versions of .NET and new functionality available in more recent versions.

Regards,

Steve

Martin Hejtmanek commented on

True, but it wouldn't really bring any new functionality or value worth so much changes. We will probably stick with current implementation until there is some real-world issue from the clients who cannot live without it. Even then, I think they should be able to use routing side by side with our rewriting if necessary.

Michiel commented on

A good reason to upgrade to ASP.NET Routing when you drop ASP.NET 2.0 support is that the implementation from Microsoft is superior.

It would mean Kentico only has to extend and build on an existing framework part, which is very extensible. It also means that developers get one central point for defining routes and hooking into the routing table, which makes integration of existing systems more predictable.

Martin Hejtmanek commented on

Yes, they certainly should! But unfortunately the reality is different. Large corporations do not like newest versions of anything and they usually stuck with one major version behind due to their internal processes and rules, so the time to go with 3.5 SP1 is about time when 4.0 SP1 comes out. The truth is some of them even hope we will stay with 2.0 for some time.

Another good news for you: With new version, we will be completely revieving the database model, indexes, statistics, execution plans, etc.

110 SQL queries seems like web site not very well designed, can you tell why you needed so much and what exactly needed the change? Of course using the default components is not that useful when dealing with complex data. Feel free to send us the details to support@kentico.com

Michiel van Oudheusden commented on

Because of your existing client base and your support for 2.0, 3.0, 3.5 etc, there is not other specific reason to go with the new System.Web.Routing.

However; Microsoft created a very nice, documented, extensible, supported routing model. If you were to create a new system, I would certainly look at this component.

Good to hear you are going to focus on 3.5. Looking forward to a good LINQ provider (with optimized SQL queries I hope). In a recent project we had to rewrite the SQL generation and data fetching because a standard page was generating 110 SQL queries which took 5 seconds to complete. Flexibility comes with a price :-)

Why no support for 3.5 SP1 ? It has a lot of bugfixes, better support for 2008. It was released on 11/18/2008 and even published with Windows Update. Shouldn't a lot of customers with version 3.5 already have installed SP1 ?

Martin Hejtmanek commented on

"You do not have to register all the available routes, but use wildcard mappings. This will force the call to a certain route where you can determine the url, fetch it from the database and create a httphandler."

I meant register the routes themselves. Of course you don't want to register all potential URLs.

"In .NET 4.0 the webforms routing is enhanced, but it is already available in .NET Framework 3.5 SP1 (and thus running under ASP.NET 2.0). But yes, you would lose support for the .NET Framework 2.0."

Yes, but SP1 makes that not acceptable for our clients yet. We plan to abandon 2.0 and go for 3.5 (not SP) during this year.

"The routing is pretty extensible compared to the simple url rewriting using httphandlers. So I don't know what you might want to improve, but with ASP.NET routing a lot is possible."

Don't know either yet ... we will see :-)

"There are even some nice extra's; expression builders for routing, automatic mapping of querystring/formdata to parameters, route parameters etc. Microsoft added a lot of functionality to the routing."

True, but it is still too small value to force us to go to higher versions of .NET and let the clients stranded.


No matter what the reasons are (I wanted to provide some rather than any) the fact is that there is no important reason to switch to ASP.NET routing, is there?

Michiel van Oudheusden commented on

* First of all, we need it to be dynamic and directed by the document data from the database.

You do not have to register all the available routes, but use wildcard mappings. This will force the call to a certain route where you can determine the url, fetch it from the database and create a httphandler.

* We still support ASP.NET 2.0, and routing for WebForms is available from .NET 4.0.

In .NET 4.0 the webforms routing is enhanced, but it is already available in .NET Framework 3.5 SP1 (and thus running under ASP.NET 2.0). But yes, you would lose support for the .NET Framework 2.0.

* We may need to improve it even more in the future, which could be hard being bound with some other solution limitations. (we still may think about it in future, we will see)

The routing is pretty extensible compared to the simple url rewriting using httphandlers. So I don't know what you might want to improve, but with ASP.NET routing a lot is possible.

* The fact that the syntax we use is the same is just a fortunate coincidence :-)

There are even some nice extra's; expression builders for routing, automatic mapping of querystring/formdata to parameters, route parameters etc. Microsoft added a lot of functionality to the routing.

I do not suggest you rewrite your existing system to the new routing from Microsoft. But your reasons are discussable.