This project is read-only.

RESTful url's using Sockets

Jul 5, 2011 at 11:23 AM

Hi Pete,

Back looking at the wonderful world of Orchard again, after a break :)

I'm curious as to whether we can construct a more RESTful url structure using the routable part, possibly via your Socket part?

I have, for example, a category type, of which there will be many items (Equine, Exotic, Farm, Large, Small, Emergency etc).  I would then like a categories page at to list the categories, and then each category to be referenced under this url via their name e.g.,, etc.

Any ideas how I could go about this, or whether it is possible with Orchard?



Jul 5, 2011 at 1:40 PM

Aha, this is what the "Plumbing" feature of Mechanics is all about :)

Specifically it gives you a "Pipe Route Part" that you can add to your Category content type and create exactly this URL structure (in the settings for Pipe Route Part).

Additionally, you could then add the "Drill Route Part" to your CategoryToProduct content type, and this would give URLs like /categories/equine/product-name. There are certain bugs with that (but I'm working on them)

Jul 5, 2011 at 1:45 PM

Thats great pete, thanks, I will take a look :)

Jul 5, 2011 at 2:23 PM

Ok I have taken a look, and functionally it works, thanks :)

There are a few bits I would like to get your comments on;

1. Could the root path be pluralised?  So Category part would be Categories?
2. Is it designed to be used instead of the Routable part?
3. Is it feasible to get the slug to be auto populated like is done with the routable part?
4. What is the checkbox under the Home / root item for?
5. I tried visiting the root page i.e. /category but it just displayed the first category item, should it list all the categories?

Nice work :)


Jul 5, 2011 at 2:38 PM

1. You can untick "Generate base route from content type name" and then enter whatever text you like in "Custom base route". I did of course think about automatic pluralisation, but it requires a lot of special-case coding to handle the intricacies of the English language (s, es, ies, etc.) So it's easier and more flexible to just have the custom override.

2. Yes it's designed to completely replace Routable part, so long as you use it in conjunction with TitlePart (which I provide as a separate component because sometimes you want a title without a route; and sometimes you might want to provide your own title-storing part, using ITitledAspect).

3. The slug is auto-populated when you publish (if you leave it blank). The way this normally works for RoutePart is kind of a hack when you look into how it's done, and can actually cause problems because it fires a Published event immediately, even though the item isn't published. So I don't want to copy how they did it, and it's a bit harder here because I have the separation of route from title. It's something I'll have eventually, along with an option to hide the slug textbox altogether if you want it never to be customisable.

4. Currently that should just set the content as the home page, but I was thinking it could also be used to choose which item would be visible on the base path for a content type route - i.e. your point 5). But I'm not sure if that's particularly useful so maybe I should just keep it as Home Page (and with a setting to disable that option).

5. Ah yes - that's the other main issue I haven't dealt with yet. I need to make a decision about how the summary display will work on root URLs. Currently the whole list is available but I'm just slicing off the first item and displaying that in detail. My top priority is dealing with DrillRoute bugs but then I'll be looking at that.