Sitecore Blog: @sitecorejohn blog

Use Wildcards to Expose User Profiles with the Sitecore ASP.NET CMS

By John West, September 07, 2011 | Rating:  | Comments (1)

The Userneme in url thread on the Sitecore Developer Network (SDNforums prompted me to write this blog post that explains how you can use wildcards to implement URLs that expose user profiles using the Sitecore ASP.NET CMS.

Sitecore wildcards are items in the content tree with a single star ("*") character for a name. Sitecore sets the wildcard item as the context item for all requests at that path level that do not map to existing items or files. You can apply layout details to the wildcard items to retrieve data frmo external systems, for example to render information about from a database about the product specified by the last part of the path in the URL. For more information about Sitecore wildcards, see the blog post Sitecore - Avoiding query string in dynamic URL by Sitecore's own Lars Fløe Nielsen, as well as Sitecore MVP Mark Cassidy's blog post Sitecore Wildcard Nodes.

You can implement a solution based on this untested prototype that renders information from the profile of the user specified by the last part of the path in the URL. If you bind this web control to the /users/* item, and no item /users/username exists, Sitecore sets the wildcard item as the context item and uses that web control for requests such as /users/username.aspx.

I expect many wildcard implementations use the same approach: parse something like Sitecore.Context.RawUrl, and then use that as an identifier to retrieve data corresponding to some part of the URL from a data source of some sort. For this specific example, unless you want to include the domain part of the username in the URL, you must somehow determine the domain (in this case, using Sitecore.Context.Domain).

If multiple presentation controls depend on parsing the URL, the first such control can add an entry to the Sitecore.Context.Items collection as demonstrated in the example, and subsequent controls can retrieve that cached object. Just be sure to use a key you can be sure that Sitecore won't use.

Whenever you implement a solution that manipulates Sitecore URLs, you have to consider two aspects: generating links, and processing HTTP requests. Wildcards deal with processing HTTP requests, but you have to generate URLS that trigger the wildcard, such as /users/username, when no such item exists. If you have similar requirements but wildcards don't quite address the requirement, you can implement an httpReuestBegin pipeline processor to set the context item according to your requirements. For more information about pipelines and pipeline processors, see my blog post All About Pipelines in the Sitecore ASP.NET CMS.

Sell also the Virtual Items in Sitecore blog post by Sitecore MVP Alistair Deneys.  

Tags: Architecture, Integration, Infrastructure, Information Architecture

Comments

  • For more information about wildcards, see:

    http://www.sitecore.net/Community/Technical-Blogs/Getting-to-Know-Sitecore/Posts/2011/09/Wildcards-and-Data-Driven-URLs.aspx

    - John West
    September 12, 2011 at 8:15 PM

*
*
*

Learn More with Sitecore

Newsletter
*

Ball State University | Read Case Study >

We're very happy with Sitecore - it allows us to push things further than we ever thought we could.

- Kyle Parker, Senior Development Group Leader and Systems Analyst, Ball State University