Reusing Sitecore Sublayouts on a Single Item

Sometimes your site design may require that the same element be reused multiple times on a single page.  Great examples of this are ad slicks, or promotional callouts - it's very conceivable that you'd have multiple promotions on a single page.  To minimize development / maintenance efforts, the best way to accomplish this is to create a single sublayout and reuse it multiple times on the given page.  The challenge in reusing Sitecore Sublayouts becomes how to differentiate the data source for each of the instances of the sublayout.  One method of differentiating the data source is to let your users pick a data source dynamically through the page editor.  However, this action might be considered advanced depending on the skillset of your user.  This method is also dependent upon your code being set up properly so that the Sitecore page editor actually works.  In the case where the developer will not be able to always determine the data source for any of the given sublayouts, this dynamic data source picking is really your only option.  But in some cases, you as a developer may be able to pinpoint the source you need for each instance of your repeated sublayout.  In these cases, there is an easy way to set up your presentation layer, and add a few lines of code to help your sublayouts determine where to find the data they need.

Take the example of having a page that has two promotional callouts.  One callout will be at the top of the page, and the other callout will be at the bottom of the page.  If we design one "CalloutPromotion" sublayout, our intention is to re-use it twice on the same page.  For the sake of this post, we'll say that each of the callouts is a single line text field defined within the page template - one field is "TopCallout", the other is "BottomCallout".  When assigning your presentation layer to your page template's standard values, add your CalloutPromotion twice - most likely having to specify a different placeholder for each to fill in.  After you have added the sublayouts, if you click on each instance of your sublayout in the presentation details dialog and click the Edit button, you can now edit properties specific to each instance of that sublayout as it relates to your individual page template.

Scroll down to the bottom of these properties and you will see a Parameters section:

You can enter whatever parameters you like in these boxes - they serve like a Key-Value pairing.  For our example, we will create a Key of "FieldName", and then populate the value with either "TopCallout" or "BottomCallout" depending on which instance of your CalloutPromotion you're editing.  When we're done, the CalloutPromotion that is to be displayed on the top of the page will look like this:

Now that we have set the parameters through for our presentation details, we simply need to code our CalloutPromotion sublayout so that it reads from our FieldName parameter.  In your Sublayout cs (code-behind) file, this can be done with the following (assumes frCallout is a FieldRenderer):

//Determine if Callout is being used as top callout or bottom callout.
string rawParameters = Attributes["sc_parameters"];
NameValueCollection parameters = Sitecore.Web.WebUtil.ParseUrlParameters(rawParameters);
string fieldName = parameters["FieldName"];

//Populate FieldRenderer with appropriate data
frCallout.FieldName = fieldName;
frCallout.DataSource = Sitecore.Context.Item.Paths.FullPath;

You now have a single sublayout control that can be reused numerous times on the same page!

Sitecore WFM / Analytics Production Set Up

If you've ever developed a Sitecore site, or know anything about Sitecore, chances are you know that its documentation is lacking (and that's being kind). This can present some real challenges, the most obvious is the reaction: "I need to do X, and it seems like it's a reasonably straight-forward possibility, but I can't find any documentation on how to achieve it". Again, if you've worked with Sitecore, you've probably had that feeling at least once. The danger in that is actually two-fold though: not only can you not find what you're working on at that time, but after a while you start morphing into the opinion "I need to do Y, but I know Sitecore's documentation won't give me what I want, so I'll not even look into it". Now not only are you missing pieces of documentation that legitimately don't exist, but you're also missing documentation that is out there. The following is from documentation that really does exist, but can be easy to overlook.

If you're trying to implement Web Forms for Marketers in a production environment, it's easy to make the mistake of installing WFM on both your Content Delivery (CD) servers as well as your Content Management (CM) servers. After awhile you may realize that your CM servers aren't reporting WFM data that's being recorded on the CD (live, production site) DB. The solution to this is to actually only install WFM on the CM server. This SDN Post explains how to get this to work. Basically, you're creating a connection string on your CD server(s) that points to a web service established when WFM was installed on your CM server.

Looking at this code snippet, which again should be in your CD config and originates from the above post:

<add connectionstring="url=http://masterhost/sitecore%20modules/shell/Web%20Forms%20for%20Marketers/Staging/WfmService.asmx;user=[domain\username];password=[password];timeout=60000" name="remoteWfmService">

"masterhost" is to be substituted with the domain of your CM site.  The [domain\username] and [password] are credentials that can be used to log into the Sitecore desktop on your CM site. 

Basically, the above has the CD server pointing back to your CM's DB, so that the CM desktop can then report on data being populated through the CD environment.  Of course, the analytics DB works almost the exact opposite to the WFM database (who needs consistency right?).  If you're implementing OMS/DMS, you'll want to have your Analytics DB set up on the CD side, and then you use a connection string on the CM side (as explained on page 13 of this document) to point to your CD DB. 

Thus, a sample production Analytics conn string may look like:

<add name="analytics" connectionString="user id=[CM_DB_User];password=[CM_DB_Password];Data Source=[CM_DB_Server];Database=Sitecore_Analytics" />
<add name="reporting" connectionString="user id=[CD_DB_User];password=[CD_DB_User];Data Source=[CD_DB_Server];Database=Sitecore_Analytics" />

The above config will allow your CM environment to collect it's own statistics for testing, but the reports within the desktop will display data that is collected on the CD environment.

So, what's important to remember is that WFM should be installed on your Content Management server and your Content Delivery server should point backwards, while your Analytics needs to be on your Content Delivery server and your Content Management server uses config to point up to it and report live production data.  That, and of course, even if Sitecore documentation is often times lacking, it's always a good idea to look rather than to assume the answers aren't already out there.