1. Expand the first sub-folder that contains the an item of type XYZ
2. Perform a sitecore query to determine which decendant folder to expand to
3. Expand the tree to a particular node depending on some attribute of the context item that i’m editing.

In my particular case, we had FacultyProfile items with a Department field (TreeList type). They wanted the Department field TreeList to be “context aware” and auto-expand to the appropriate part of the Department Lookup tree depending on the Site that the FacultyProfile item was in. My solution was to extend Sitecore’s TreeList type to add the necessary functionality as detailed below.

Taking a look at the inner workings of the TreeList type (thank you .NET Reflector), I found that the TreeList type uses the TreeviewEx control to render the tree. The TreeviewEx control uses a DataContext control to set the Root folder and the start Folder. After some more digging, trial & error I came up with the following extended data type (how to create an extended data type):

namespace Drexel.CustomTypes
{
    public class SmartTreeList : TreeList
    {
        protected override void OnPreRender(EventArgs e)
        {
            base.OnPreRender(e);

            if (this.ItemID != null)
            {
                var tree = (TreeviewEx)this.FindControl(this.ID + "_all");
                var dc = FindDataContext(this);
                var item = Sitecore.Context.ContentDatabase.GetItem(this.ItemID);

                var pipeArgs = new PreRenderSmartTreeListArgs(item, dc);
                CorePipeline.Run("PreRenderSmartTreeList", pipeArgs);

                if (!string.IsNullOrEmpty(pipeArgs.DataContext.Folder))
                {
                    // 'Select' the Folder item in addition to expanding it...
                    var i = item.Database.GetItem(pipeArgs.DataContext.Folder);
                    if (i != null)
                        tree.SetSelectedItem(i);
                }
            }
        }

        private DataContext FindDataContext(System.Web.UI.Control c)
        {
            DataContext dc = null;

            if (c is DataContext)
                dc = (DataContext)c;
            else
            {
                foreach (System.Web.UI.Control ctl in c.Controls)
                {
                    dc = FindDataContext(ctl);
                    if (dc != null)
                        break;
                }
            }

            return dc;
        }
    }
}

I decided to use a custom Sitecore pipeline for my SmartTreeList type. Here’s a great synopsis of how to create a custom pipeline. This allows me to apply different logic for determining the “Start Folder” depending on the context item. So, in the OnPreRender event, I find DataContext control and get a reference to the Context Item. Then I call my custom pipeline which only contains 1 pipeline processor: FacultyProfileDepartmentProcessor.

First, the pipeline code…

    interface IPreRenderSmartTreeListProcessor
    {
        void Process(PreRenderSmartTreeListArgs args);
    }

    public class PreRenderSmartTreeListArgs : PipelineArgs
    {
        public PreRenderSmartTreeListArgs(Item item, DataContext dc)
        {
            this.Item = item;
            this.DataContext = dc;
        }

        public Item Item { get; set; }
        public DataContext DataContext { get; set; }
    }

    public class FacultyProfileDepartmentProcessor : IPreRenderSmartTreeListProcessor
    {
        public void Process(PreRenderSmartTreeListArgs args)
        {
            if (args.Item != null && args.Item.TemplateName == "FacultyProfile")
            {
                // My logic to determine the correct Department node to open...
                // ...
                // ...
                args.DataContext.Folder = pathOrItemIdOfDepartmentItem;
            }
        }
    }

Then, add the configuration for the pipeline:

   ...
      <PreRenderSmartTreeList>
        <processor type="Drexel.Pipelines.PreRenderSmartTreeList.FacultyProfileDepartmentProcessor, Sitecore.Drexel.Pipelines" />
      </PreRenderSmartTreeList>
   ...

That’s it. Relatively simple… relatively extensible. Just the way I like it..

1. Extend the “SqlProxyDataProvider” class

using System;
using System.Collections.Generic;
using System.Configuration;
using System.Linq;
using System.Text;

using Sitecore.Configuration;
using Sitecore.Data;
using Sitecore.Data.DataProviders.Sql;
using Sitecore.Data.Items;
using Sitecore.Data.Proxies;
using Sitecore.Data.SqlServer;

using BaseIDs = Drexel.FieldIDs.Base;
using Drexel.Extensions;

namespace Drexel.Data.SqlServer
{
public class SqlServerProxyDataProvider : SqlProxyDataProvider
{
private string _connectionString = string.Empty;
private Dictionary<string, bool> _validIdLookup = new Dictionary<string, bool>();

private Database _db;
private Database ContextDb
{
get
{
if (_db == null)
{
try
{
ConnectionStringSettings css = ConfigurationManager.ConnectionStrings
.Cast<ConnectionStringSettings>()
.SingleOrDefault(x => x.ConnectionString == _connectionString);
_db = Factory.GetDatabase(css.Name);
}
catch (Exception ex)
{
Drexel.Logging.Log.Error("Failed to resolve connection string", ex);
_db = Factory.GetDatabase("master"); // Default to master DB
}
}
return _db;
}
}
private SqlServerDataApi API { get; set; }
public SqlServerProxyDataProvider(string connectionString)
: this(new SqlServerDataApi(connectionString), true)
{
_connectionString = connectionString;
}
private SqlServerProxyDataProvider(SqlServerDataApi api, bool foo)
: base(api)
{
this.API = api;
}
public override ID GetVirtualId(ID itemId, ID proxyId, bool generateIfNotFound)
{
ID proxySourceItemID;
string vcProxyFilterQuery;
bool valid = true;

if (!_validIdLookup.TryGetValue(itemId.ToString(), out valid))
{
valid = true; // if TryGetValue fails, it sets valid=false...
GetProxyFilterInfo(proxyId, out proxySourceItemID, out vcProxyFilterQuery);

if (!string.IsNullOrEmpty(vcProxyFilterQuery) && !proxySourceItemID.IsNull)
{
using (new ProxyDisabler())
{
string[] validIds = GetValidProxyIds(proxyId, proxySourceItemID, vcProxyFilterQuery);
valid = validIds.Contains(itemId.ToString());
}
}

_validIdLookup.Add(itemId.ToString(), valid);
}

if (valid)
return base.GetVirtualId(itemId, proxyId, generateIfNotFound);
else
{
// See if this proxied item was already shadowed... if so, then remove it
ID shadowId = base.GetVirtualId(itemId, proxyId, false);
if (shadowId != (ID)null)
this.RemoveShadow(shadowId);
return ID.Null;
}

}

private string[] GetValidProxyIds(ID proxyId, ID proxySourceItemID, string vcProxyFilterQuery)
{
System.Web.Caching.Cache cache = System.Web.HttpContext.Current.Cache;
Item proxyItem = ContextDb.GetItem(proxyId);
string vcCacheKey = "ValidProxyIdsFor-" + proxySourceItemID.ToString() + "-" + GetItemTimestamp(proxyItem);

string[] list = (string[])cache[vcCacheKey];
if (list == null)
{
Item i = ContextDb.GetItem(proxySourceItemID);
list = i.Axes.SelectItems(vcProxyFilterQuery).Select<Item, string>(x => x.ID.ToString()).ToArray();
cache.Insert(vcCacheKey, list, null, DateTime.Now.AddMinutes(10.0), System.Web.Caching.Cache.NoSlidingExpiration);
}
return list;
}
private string GetItemTimestamp(Item i)
{
ID[] fields = new ID[] { Sitecore.FieldIDs.Updated, Sitecore.FieldIDs.Created };
return Sitecore.DateUtil.IsoDateToDateTime(i.FieldCoalesce(fields).Value, DateTime.MinValue).ToString("yyyyMMddHHmmss");
}
private void GetProxyFilterInfo(ID proxyId, out ID ProxySourceItemID, out string vcProxyFilterQuery)
{
ProxySourceItemID = ID.Null;
vcProxyFilterQuery = string.Empty;
string sql = @"select f.{0}FieldID{1}, f.{0}Value{1} from {0}Items{1} i inner join {0}Fields{1} f on f.{0}ItemId{1} = i.{0}ID{1} " +
@"where i.{0}ID{1} = {2}proxyId{3} and f.{0}FieldID{1} in ({2}queryFieldId{3}, {2}proxySourceItemFieldId{3})";

object[] parameters = new object[] { "proxyId", proxyId,
"queryFieldId", BaseIDs.ProxyFilter.Query,
"proxySourceItemFieldId", Sitecore.FieldIDs.ProxySourceItem };

using (DataProviderReader reader = this.API.CreateReader(sql, parameters))
{
while (reader.Read())
{
ID id = this.API.GetId(0, reader);
if (id == Sitecore.FieldIDs.ProxySourceItem)
ProxySourceItemID = ID.Parse(this.API.GetString(1, reader));
else if (id == BaseIDs.ProxyFilter.Query)
vcProxyFilterQuery = this.API.GetString(1, reader);
}
}
}

private void RemoveShadow(ID shadowId)
{
string sql = " DELETE FROM {0}Shadows{1} WHERE {0}ShadowID{1} = {2}shadowId{3}";
this.API.Execute(sql, new object[] { "shadowId", shadowId });
}

}
}

2. Extend “ItemProvider” class

using System;
using System.Collections.Generic;
using Sitecore;
using Sitecore.Collections;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Data.Proxies;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Layouts;
using Sitecore.SecurityModel;
using Sitecore.StringExtensions;

namespace Drexel.Data.Managers
{
    public class ItemProvider : Sitecore.Data.Managers.ItemProvider
    {
        public ItemProvider() : base() { }

        public override ChildList GetChildren(Item item, SecurityCheck securityCheck)
        {
            Assert.ArgumentNotNull(item, "item");
            ItemList children = this.GetChildren(item);
            this.InsertVirtualChildren(children, item);
            children.RemoveAll(x => x == null); // remove nulls
            return new ChildList(item, this.ApplySecurity(children, securityCheck));
        }
    }
}

3. web.config changes..

    <proxyDataProviders>
      <main type="Drexel.Data.$(database).$(database)ProxyDataProvider, Sitecore.Drexel">
        <param connectionStringName="$(1)" />
        <Name>$(1)</Name>
      </main>
      <!--<main type="Sitecore.Data.$(database).$(database)ProxyDataProvider, Sitecore.Kernel">
        <param connectionStringName="$(1)" />
        <Name>$(1)</Name>
      </main>-->
    </proxyDataProviders>
...
 <itemManager defaultProvider="default">
      <providers>
        <clear />
        <add name="default" type="Drexel.Data.Managers.ItemProvider, Sitecore.Drexel" />
        <!--<add name="default" type="Sitecore.Data.Managers.ItemProvider, Sitecore.Kernel" />-->
      </providers>
    </itemManager>

How it works now…

The LinkBuilder.ResolveTargetSite method is responsible for determining what host name to use if the requested item is outside the scope of the context site. To do this, it builds a “SiteResolvingTable” which consists of Dictionary object where the key is:

Site.RootPath + Site.StartItem

RootPath and StartItem come from the attribute values for each site as defined in your <sites> web.config section. The next step is to take the fullpath to the requested item and recursively chop off the last part of the path and try to match it up to one of the sites in the SiteResolvingTable. Like this:

Requested item: /sitecore/content/home/mysite/path1/path2/path3/myitem

1. No match? Ok try: /sitecore/content/home/mysite/path1/path2/path3
2. No match? Ok try: /sitecore/content/home/mysite/path1/path2
3. No match? Ok try: /sitecore/content/home/mysite/path1
4. etc…

When/if it finds a match, it takes the “TargetHostName” attribute (or “HostName” if there are no ‘*’ or ‘|’ characters in it) and builds the URL: http://TargetHostName/{ItemPath}.

The problem…

From the web.config documentation:

/*
  rootPath: The path to the root item of the site.
            The item path specified in the URL will be appended to this value to find the item.

  startItem: The path to the start item of the site.
             This is used as the default item path if no path is specified in the URL.
             It will be combined with rootPath to find the default item of the site.
*/

So why is StartItem included in the SiteResolvingTable key? It makes no sense to me… it must be a bug. The key should just be RootPath. No problem! We configuring “/” as the StartItem. The problem here is that all keys in the SiteResolvingTable will then end with “/”. The ItemPath logic above chops off the trailing slashes when recursing up the item path and so we’d never resolve any of our sites.

UPDATE: I contacted Sitecore support about this issue and they are aware of the issue and have it registered as a bug. Read more about it here. Still, if their suggested work-arounds do not work for you, read on…

UPDATE 2: Sitecore support has informed me that  “The issue is fixed in Sitecore 6.4.1 rev.110928. You can find the following entry in the Release Notes.”

In the end, we decided to override Sitecore’s logic to build the SiteResolvingTable. I hate overriding things like this because eventually the overridden code will change (with new versions) and you start missing out on bug fixes. So hopefully they fix it and I can remove this. Here’s the custom LinkProvider we built:

    ///
<summary> /// Extensions for the Sitecore.Links.LinkProvider class
 /// </summary>
    public class LinkProvider : Sitecore.Links.LinkProvider
    {
        private delegate string KeyGetter(SiteInfo siteInfo);

        public override string GetItemUrl(Item item, UrlOptions options)
        {
            string itemUrl;

            options.SiteResolving = Sitecore.Configuration.Settings.Rendering.SiteResolving;

            // Use our custom LinkBuilder that fixes the SiteResolvingTable...
            var builder = new LinkBuilder(options);
            itemUrl = builder.GetItemUrl(item);

            return itemUrl;
        }

        private static string GetTargetHostName(SiteInfo siteInfo)
        {
            if (!siteInfo.TargetHostName.IsNullOrEmpty())
                return siteInfo.TargetHostName;

            string hostName = siteInfo.HostName;
            if (hostName.IndexOfAny(new char[] { '*', '|' }) < 0)
                return hostName;

            return string.Empty;
        }

        public new class LinkBuilder : Sitecore.Links.LinkProvider.LinkBuilder
        {
            // Fields
            private readonly UrlOptions _options;
            private static Dictionary _siteResolvingTable;
            private static List _sites;
            private static readonly object _syncRoot;

            static LinkBuilder() { _syncRoot = new object(); }
            public LinkBuilder(UrlOptions options) : base(options) { _options = options; }

            protected override SiteInfo ResolveTargetSite(Item item)
            {
                SiteContext site = Context.Site;
                SiteContext context2 = this._options.Site ?? site;
                SiteInfo info = (context2 != null) ? context2.SiteInfo : null;
                if (!this._options.SiteResolving || (item.Database.Name == "core"))
                {
                    return info;
                }
                if ((this._options.Site != null) && ((site == null) || (this._options.Site.Name != site.Name)))
                {
                    return info;
                }
                if ((context2 != null) && item.Paths.FullPath.StartsWith(context2.StartPath))
                {
                    return info;
                }
                Dictionary siteResolvingTable = GetSiteResolvingTable();
                string key = item.Paths.FullPath.ToLower();
            Label_00AE:
                if (siteResolvingTable.ContainsKey(key))
                {
                    return siteResolvingTable[key];
                }
                int length = key.LastIndexOf("/");
                if (length > 1)
                {
                    key = key.Substring(0, length);
                    goto Label_00AE;
                }
                return info;
            }

            private static Dictionary GetSiteResolvingTable()
            {
                List sites = SiteContextFactory.Sites;
                if (!object.ReferenceEquals(_sites, sites))
                {
                    lock (_syncRoot)
                    {
                        if (!object.ReferenceEquals(_sites, sites))
                        {
                            _sites = sites;
                            _siteResolvingTable = null;
                        }
                    }
                }
                if (_siteResolvingTable == null)
                {
                    lock (_syncRoot)
                    {
                        if (_siteResolvingTable == null)
                        {
                            _siteResolvingTable = BuildSiteResolvingTable(_sites);
                        }
                    }
                }
                return _siteResolvingTable;
            }

            private static Dictionary BuildSiteResolvingTable(IEnumerable sites)
            {
                Dictionary dictionary = new Dictionary();
                List list = new List();
                //KeyGetter[] getterArray = new KeyGetter[] { info => FileUtil.MakePath(info.RootPath, info.StartItem).ToLower() };
                KeyGetter[] getterArray = new KeyGetter[] { info => info.RootPath.ToLower() };
                foreach (KeyGetter getter in getterArray)
                {
                    foreach (SiteInfo info in sites)
                    {
                        if (!string.IsNullOrEmpty(info.HostName) && string.IsNullOrEmpty(GetTargetHostName(info)))
                        {
                            Sitecore.Diagnostics.Log.Warn("LinkBuilder. Site '{0}' should have defined 'targethostname' property in order to take participation in site resolving process.".FormatWith(new object[] { info.Name }), typeof(LinkProvider.LinkBuilder));
                        }
                        //else if ((!string.IsNullOrEmpty(GetTargetHostName(info)) && !string.IsNullOrEmpty(info.RootPath)) && !string.IsNullOrEmpty(info.StartItem))
                        else if (!string.IsNullOrEmpty(GetTargetHostName(info)) && !string.IsNullOrEmpty(info.RootPath))
                        {
                            string key = getter(info);
                            if (!list.Exists(new Predicate(key.StartsWith)))
                            {
                                dictionary.Add(key, info);
                                list.Add(key);
                            }
                        }
                    }
                }

                return dictionary;
            }
        }
    }

In my case, I wanted to just add this information into the existing (default) LogFileAppender. To do this, I extended Sitecore’s “SitecoreLogFileAppender” class as follows:

public class SitecoreLogFileAppenderEx : log4net.Appender.SitecoreLogFileAppender
{
    protected override void Append(LoggingEvent loggingEvent)
    {
        var properties = loggingEvent.Properties;

        properties["scuser"] = string.Empty;
        properties["scitemid"] = string.Empty;
        properties["rawurl"] = string.Empty;

        // Only log ERRORS or higher level events
        if (Sitecore.Context.Site != null && loggingEvent.Level >= Level.ERROR)
        {
            if (Sitecore.Context.User != null)
                try { properties["scuser"] = Sitecore.Context.User.Name; }
                catch { }
            if (Sitecore.Context.Item != null)
                try { properties["scitemid"] = Sitecore.Context.Item.ID.ToString(); }
                catch { }

            try { properties["rawurl"] = Sitecore.Web.WebUtil.GetServerUrl() + Sitecore.Web.WebUtil.GetRawUrl(); }
            catch { }
        }
        base.Append(loggingEvent);
    }
}

Then i modified the web.config log4net configuration to use my appender and added the custom properties to the PatternLayout as follows.:

		<appender name="LogFileAppender" type="log4net.Appender.SitecoreLogFileAppenderEx, Sitecore.Drexel.Logging">
			<file value="$(dataFolder)/logs/log.{date}.txt"/>
			<appendToFile value="true"/>
			<layout type="log4net.Layout.PatternLayout">
				<conversionPattern value="%4t %d{ABSOLUTE} %-5p %c [%P{scuser} %P{scitemid} %P{rawurl}] %m%n"/>
			</layout>
		</appender>

It is important to note that when specifying the parameters in the PatternLayout, you must use a capital “P”.

Good so far! By default, Sitecore will pass some parameters to your UserControl page (taken right from the sitecore documentation):

• id – The GUID of the item selected by the user.
• la – The language code selected by the user.
• vs – The version number selected by the user.

Super! What if i have multiple iFrame fields on my item that point to the same UserControl though? What’s missing? How about what field am I supposed to be loading from.

This isn’t really a big deal though because the iFrame field type also allows you to specify extra parameters when you set the URL to your UserControl in the field data source. I pass an extra “?field=my-field-name” parameter to the end of my iFrame data source when necessary to avoid this issue. Then in the Page_Load of my UserControl I can use it like so:

if (!IsPostBack)
{
Database db = Factory.GetDatabase("master");
Item myItem = db.GetItem(Request.Params["id"]);
string fieldvalue = myItem[Request.Params["field"]];

// ...
// code to load my control with "fieldvalue"
// ...

}

Having dealt with many requests for this type of component, I decided it would be worth the time to try coming up with a more generic solution. What I came up with was the concept of “Datasets” and “DatasetRenderers”. What follows in this post is a super-high-level-overview of what “Datasets” and “DatasetRenderers” have become…

In the typical custom component scenario you have a custom control and possibly a specific item type for storing extra rendering information. In a “Dataset” scenario there are always 3 pieces: the Dataset item, the DatasetRenderer item, and the DatasetRenderer control.

The “Dataset item” is used to specify the set of data we are working with, but NOT how that data gets rendered. There are currently 4 types of Datasets:

• ItemsQuery – sitecore query
• StaticItemSet – manually choose sitecore items (TreelistEx)
• DatabaseQuery – SQL query against an external data source
• SharepointQuery – web services query against a Sharepoint list or view

The “DatasetRenderer item” contains all the rendering information necessary to display data for the parent Dataset. A DatasetRenderer item is always the child of a Dataset item. A Dataset item may have more than one child DatasetRenderer.

The “DatasetRenderer control” is a server control that points to a DatasetRenderer item as it’s data source. It understands how to interpret the rendering information on the DatasetRenderer Item and apply it to the data from the Dataset.

At this point, I’m sure this is clear as mud… so how about a sample. A real, working, live sample in fact, from: http://drexel.edu/irt/help/workshops/

This page on Drexel’s website is used to provide information about upcoming workshops, demos, and training. Each of the tables on the page are dynamically populated with data from a single Sharepoint list. In the “Presentation Details” for the /irt/help/workshops item there are several DatasetRenderer controls (one for each table) each pointing to a DatasetRenderer item.

The “WorkshopsList” is a SharepointQuery dataset with several child DatasetRenderer items. I’m not going to go into any detail about the parameters in this post but you can see there are several parameters for a SharepointQuery dataset. Next, let’s take a look at what the “BbVista” datasetrenderer item looks like…

There are many more options than can be easily captured in a single screen shot so the above image only shows the most important fields.

• “List Item Fields” – contains all the available fields in the underlying dataset.
• “List Item Template” – defines what HTML is output for each row in the dataset
• “Alternating List Item Template” – allows you to define different output for alternating rows

When the DatasetRenderer above was first created, all the fields except “List Item Fields” were empty. The user decided they wanted to output the contents of the dataset into a HTML table. They entered the HTML in the fields as shown using the “List Item Fields” field as a reference to choose fields to place in the “List Item Template” field with the syntax [fieldname], such as the [Start Date] field. There is quite a bit more functionality available in the template fields (like the @formatdate function) but that’s for another post.

At this point you might ask… “Isn’t it a bad idea to allow the end user direct access to the output HTML?” Yes, but no more dangerous than a native Sitecore RichText field. Ultimately, if end users want to abuse the system… they find a way.

The extra tabs available at the top, Dataset (preview) and Output (preview) are particular useful for users. The Dataset (preview) tab shows a no frills asp.net datagrid of the raw data in the dataset.

The Output (preview) table shows the html output of the DatasetRenderer.

I think this is a fine place to stop with the high level overview of what Datasets & DatasetRenderers are. There is really too much information (caching, @functions, renderer fields, etc…) for me to try covering in a single post and I’d rather wait to see if there are any interested Sitecore enthusiasts out there before posting more or perhaps even turning this into a Shared Source project (of course I’d need to get approval from “powers that be” before that could happen).

Happy coding!

taskkill /f /im Webdev.WebServer.exe
cmd /c start /D"C:\Program Files\Common Files\microsoft shared\DevServer\9.0\" Webdev.WebServer.exe /port:81 /path:"c:\<path-to-your-sitecore-website>\WebSite"
ping 127.0.0.1 -n 3 -w 1000 > nul
cmd /c start /D"C:\Program Files\Internet Explorer\" iexplore.exe http://localhost:81/sitecore

This script does the following:

1. Kills any running Dev webserver instances
2. Starts a new Dev webserver instance running your sitecore website
3. Waits a few seconds (for the webserver to spin up)
4. Opens Internet Explorer to the sitecore website

So after I run this batch file, I then attach to the WebDev.WebServer process and start debugging (actually, i use a VS macro for this). That’s it!

• /sitecore/content/Home
  • SiteA
    • ItemA1
  • SiteB
    • ItemB1

If you had a custom control on SiteA that used LinkManager.GetItemURL(ItemB1), the return URL would be something like:

www.SiteA.com/sitecore/content/home/SiteB/ItemB1

when what you really want is:

www.SiteB.com/ItemB1

Several people in my group searched high and low for a Sitecore configuration that would result in exactly that. After much research, it seemed that the undocumented “SiteResolving” setting is what we needed.

To get SiteResolving to work, you need to:

1. Set the targetHostName on the desired site config entries
2. When calling LinkManager.GetItemUrl, pass in UrlOptions with UrlOptions.SiteResolving=true.

It seems that if targetHostName is set and UrlOptions.SiteResolving=true, then when a GetItemUrl request is made to the LinkProvider it will check whether the requested item is a descendant of the context site. If not, then the SiteResolving logic kicks in. This logic takes the requested item path and recursively chops off the last part of the path until a match is found. The match is against the site config’s RootPath+StartItem. If a match is found, that site’s targetHostName is used when generating the URL.

However, the trickiness is really setting UrlOptions.SiteResolving to true, unless you are going to remember to explicitly set this each time you call LinkManager.GetItemUrl. You would think adding the following web.config setting would do the trick:

<setting name=”Rendering.SiteResolving” value=”true” />

But the neither the LinkProvider code nor the default UrlOptions seem to use this. So, in order to get this to work, I just added the following code to my custom LinkProvider:

public class LinkProvider : Sitecore.Links.LinkProvider

{

public override string GetItemUrl(Item item, UrlOptions options)

{

string itemUrl;

//other code

options.SiteResolving = Sitecore.Configuration.Settings.Rendering.SiteResolving;

itemUrl = base.GetItemUrl(item, options);

//other code

return itemUrl;

}

}

}

Thanks to Mike Casey for helping find this solution.

…

I built a Sitecore command (usable from the “MyToolbar” in Content Editor) that dynamically builds a DLL containing my sites template field IDs (just like Sitecore.FieldIDs in the Sitecore.Kernel) mapped to string constants.

Why? Well the reason for creating the DLL can be found in this post and I made it dynamic so I wouldn’t have to maintain this library every time we decided to change a template…. and just to see if i could.

Code at the end of this post contains the class that does the creation/compiling. Beyond that, there are a few steps to get it up as a command. There may be some extra or unnecessary steps (let me know), but this is what I did.

1. Put the class code in and build your own class library (sitecore.foo.dll)
2. In Commands.config for your Sitecore installation, add an entry that references this DLL

<command name=”foo:buildfieldids” type=”MyNamespace.Commands.FieldIDsGenerator,sitecore.foo” />

3. Now we need to add the ribbon button. Go into the Sitecore Core Database content editor.
4. Create a new chunk item (for this example called: MyChunk) in /sitecore/content/Applications/Content Editor/Ribbons/Chunks
5. In MyChunk create a button item. Choose the header: “Generate FieldIDs DLL” and icon. In “Click” put “foo:buildfieldids”.
6. Right click on the ribbon in content editor. Enable “My Toolbar” and choose “Customize”
7. Find your MyChunk and add the new button to the toolbar
8. Finally, in web.config for the Sitecore installation add these appSettings:
    <add key=”FieldIDsGenerator.DLLName” value=”Sitecore.MyNamespace.FieldIDs”/>
    <add key=”FieldIDsGenerator.Namespace” value=”MyNamespace.FieldIDs”/>
    <add key=”FieldIDsGenerator.RootTemplateQuery” value=”/sitecore/Templates/MyTemplates/*”/>

Done. Try clicking the new button and take a look at the generated code.

Sample usage:

using IDs = MyNamespace.FieldIDs;

public partial class Generic_Page : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Page.Title = Sitecore.Context.Item[IDs.TemplateName.FieldName];
    }
}

Hope this helps.
Feel free to suggest improvements and/or ridicule me as you see fit

The code…

using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Configuration;
using System.IO;
using Microsoft.CSharp;
using System.CodeDom.Compiler;
using System.Reflection;
using System.Text.RegularExpressions;
using Sitecore.Collections;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Data.Fields;
using Sitecore.Shell.Framework.Commands;
using Sitecore.Diagnostics;
using System.Linq;

namespace YourCompany.Commands
{
    /// <summary>
    /// Command that dynamically builds & compiles the Sitecore.YourCompany.FieldIDs.dll
    /// and places it in the bin of the current sitecore installation.
    /// </summary>
    [Serializable]
    public class FieldIDsGenerator : Command
    {
        Regex _rgxCleanName = new Regex(@"[\W]*");

        // Methods
        public override void Execute(CommandContext context)
        {
            try
            {
                BuildFieldIDsDLL();
                Sitecore.Context.ClientPage.ClientResponse.Alert("Successfully rebuilt DLL");
            }
            catch (Exception ex)
            {
                Sitecore.Context.ClientPage.ClientResponse.Alert("Error: " + ex.Message);
            }
        }

        public override CommandState QueryState(CommandContext context)
        {
            Error.AssertObject(context, "context");
            if (!Sitecore.Context.IsAdministrator)
            {
                return CommandState.Disabled;
            }
            return base.QueryState(context);
        }

        private void BuildFieldIDsDLL()
        {
            string dllName = ConfigurationManager.AppSettings["FieldIDsGenerator.DLLName"];
            string baseNamespace = ConfigurationManager.AppSettings["FieldIDsGenerator.Namespace"];
            string templateQuery = ConfigurationManager.AppSettings["FieldIDsGenerator.RootTemplateQuery"];

            // Create the DLL in the Sitecore/bin directory
            Directory.SetCurrentDirectory(Sitecore.Install.Files.PathUtils.MapPath("/bin"));

            // Creates a text file to store the new class
            using (StreamWriter sr = File.CreateText(dllName + ".cs"))
            {
                sr.WriteLine("using System;");
                sr.WriteLine("using Sitecore.Data;");
                sr.WriteLine("");
                sr.WriteLine("namespace " + baseNamespace);
                sr.WriteLine("{");
                Item[] items = Sitecore.Context.ContentDatabase.SelectItems(templateQuery);
                foreach (Item item in items)
                {
                    BuildTemplateFieldIDClass(sr, item);
                }

                sr.WriteLine("}");
            }

            // Create C# compiler
            CSharpCodeProvider csc = new CSharpCodeProvider();
            ICodeCompiler icc = csc.CreateCompiler();

            // input params for the compiler
            CompilerParameters co = new CompilerParameters();
            co.OutputAssembly = dllName + ".dll";
            co.ReferencedAssemblies.Add("system.dll");
            co.ReferencedAssemblies.Add("Sitecore.Kernel.dll");

            // generate a DLL
            co.GenerateExecutable = false;

            // Run the compiler
            icc.CompileAssemblyFromFile(co, dllName + ".cs");
        }

        private void BuildTemplateFieldIDClass(StreamWriter sr, Item item)
        {

            string className = _rgxCleanName.Replace(item.Name, "");
            string memberName = null;

            switch (item.Template.Name)
            {
                case "Template Folder":

                    // Write the namespace...
                    sr.WriteLine("namespace " + className);
                    sr.WriteLine("{");

                    // Build base template classes
                    ChildList children = item.GetChildren();
                    foreach (Item child in children)
                    {
                        BuildTemplateFieldIDClass(sr, child);
                    }

                    // End the namespace...
                    sr.WriteLine("}");

                    break;

                // Check if class has already been created and it has it's own fields
                case "Template":

                    TemplateItem ti = (TemplateItem)item;

                    if (ti.OwnFields.Length > 0)
                    {
                        // Write the class...
                        sr.WriteLine("public static class " + className);
                        sr.WriteLine("{");

                        // Write the class members...
                        foreach (TemplateFieldItem tfi in ti.OwnFields)
                        {
                            sr.Write("\tpublic static ID ");

                            memberName = _rgxCleanName.Replace(tfi.Name, "");
                            if (className == memberName) memberName = "_" + memberName;

                            sr.Write(memberName);
                            sr.Write(" = new ID(\"");
                            sr.Write(tfi.ID.ToString());
                            sr.Write("\");\n");
                        }

                        // End the class...
                        sr.WriteLine("}");

                    }
                    break;
            }
        }
    }
}

But until then…

Proxy Items in Sitecore would be really useful if there was more flexibility as to which Items are “proxied”. With the current design, there are only a few options regarding which items to shadow: 1 item, all the children of a target item, or all descendants under a target item. That’s great and all, but it would be more useful (at least for the cases I need it) if you could somehow specify a subset of items under a target item. With this need in mind, I pieced together ProxyFilter.

I added the ProxyFilter section to the Proxy template with a field called “Query”. In this field, you enter a sitecore query you would like used to filter the virtual items that the proxy points to. This all works by extending the “SqlServerProxyDataProvider” class… along with a small extension to “ItemProvider”.  I’m not going to go into the code here unless someone actually wants it because as I said above, this was more a proof of concept and it will most likely become unnessary with Sitecore’s MASSIVE release.

ProxyFilter in action… On the left, is the set of virtual items you get setting up a regular Proxy item. On the right, is the filtered subset of virtual items created as a result of the ProxyFilter settings in the screenshot above.

One issue I did notice was that the ProxyProvider contains a ProxyCache object which among other things stores VirtualIds. But it seems to store them indefinitely. The reason this is bad is that when I update the Proxy item.. say to point to a different source item, it doesn’t update the virtual items until the cache is cleared.

And there you have it… ProxyFilter.