Fixing Ugly Hierarchical DynamicContent Urls

April 02, 2013
The module builder gives is a lot of power, and a little while ago it was enhanced to allow nested types.

Exhibit A:



So using the default front-end control, to get to a "case" it always has to render it's parent out...that's how it knows which "case" to load (if it wasn't there you might have 2 cases in different libraries with the same url name).  Clearly it exists this way because the general user has no idea about routing, they just want to drop the control on the page and have it work.

Here's the problem with that...the url ends up being ugly if you're not using the control if "full" "default" dynamic mode.

By that I mean lets say you have a page created to show JUST detail items.
/<library>/detail/<case>
...this type of setup allows your "detail" view to have a different page template than the master listview right.

SOOO...with the default control on both the master and the detail page, and the master control set to open detail items on the detail page this is what your url would look like.
/mylibrary/detail/mylibrary/mycase

...redundant as all hell.

So whats the fix, well it's actually not too hard to implement, but it would be AWESOME if telerik could include this ability in a future version of the control.

public class HierarchicalContentViewBase : HierarchicalContentView {
    /// <summary>
    /// Remove the parent route from the item
    /// </summary>
    /// <returns></returns>
    protected override bool IsSingleItem() {
        //Check to see if the property is set
        if (!String.IsNullOrEmpty(this.ParentUrlName))
        {
            DynamicContent item = null;
            string redirectUrl = string.Empty;
 
            //Re-form the url appending the parent
            var urlParams = "/" + this.ParentUrlName.TrimStart('/').TrimEnd('/') + this.GetUrlParameterString(true);
            item = this.TryGetFromTypeSuccessors(urlParams, true, ref redirectUrl);
 
            if (item != null)
            {
                this.DetailItem = item; //Assign the located detail item to the control
                RouteHelper.SetUrlParametersResolved(); //Tell SF "It's all cool"
 
                return true;
            }
            else
            {
                //Perhaps call the base here instead, unsure, thor what say you?
                return false;
            }
        }else{
            //If it hasn't been defined, perform the default base method
            return base.IsSingleItem();
        }
    }
 
 
    private string _parentUrlName = String.Empty;
    /// <summary>
    /// Allows the user to define the parent url for the route
    /// </summary>
    public string ParentUrlName {
        get { return _parentUrlName; }
        set { _parentUrlName = value; }
    }
}

We're just inheriting from the DEFAULT control, and TELLING it what the parenturl is, so it's not inferring from the url.  The beauty is that it only does anything if the ParentUrlName is set, if it isn't the control behaves as it always would.

So from here all you need to do is compile and change the "Control CLR Type or Virtual Path" field in the toolbox to be your custom control instead of the default.

(NOTE: Don't forget to actually SET the parenturlname when editing the advanced properties of the control)

Steve


Image Description

Steve McNiven-Scott

Best\Only Blogger on this site. Therefore defacto blogger of the year Award Winner.