I won’t sing the praises of IntelliJ here, but there is no shortage of discerning Java developers who prefer it to the alternative Java IDEs. But more than IDEology, it’s important to have a light-weight tool (or plugin) that can fit into a developer’s existing IDE and development process. CRXDE seems to be intended as a complete and self-contained solution to CQ5 development. As such, it may not provide the flexibility to interface with the other tools in a developer’s chest. Velir’s plugin, by being more lightweight, attempts to fill a niche for developers who want a customized CQ5 development process.

A good VCS (Version Control System) is a necessity for long-term success in software development.  Although the JCR specification has some support for content versioning, it is not intended to be a robust VCS. Most teams working with CQ5 have relied on Adobe’s FileVault (vlt) tool to import/export JCR content from the JCR to the file system in XML form.  This content is then stored in the team’s VCS of choice.  This extra layer of check-in and check-out from vlt adds another step to software development that feels a bit awkward when you first begin developing on the CQ5 platform. Velir’s IntelliJ plugin is based on the same XML format that is found in JCR content exported by vlt, but the plugin can handle import/export directly. Dialogs are provided that allow for easy editing of JCR content, and creation of common CQ5 nodes like cq:Component. It also provides suggestions for node creation based on the type of the parent node you’re creating it under. It is actually more robust than CRXDE in a few cases (try editing an array of booleans in CRXDE), although a user will probably still want to use CRXDE (or CRXDE light) for some things like search.

Since JCR import/export functionality has been developed recently, it may have some bugs. Please be careful when importing files to CQ5’s /lib and /etc directories, or you may have to reinstall CQ5.

Velir plans to add many more features, including

• JCR-centric view showing nodes and their properties, the way CRXDE does
• Ability to display files directly from the JCR
• Automatic syncing of content between the JCR and filesystem
• Search for content within the JCR
• Clickthrough from Sling/CQ includes in JSPs to OSGI servlet bundle code

You can find the plugin at https://github.com/Velir/intelliJ-jcr-plugin. Contributors/suggestions/bug reports are welcome!

We’re introducing our newest module for Sitecore which is called the Item URL Helper.

The Item URL Helper adds two great features to the Content Manager that will enrich your life as a content editor or developer. The first is the ability to right click an item and have the item’s URL copied directly to your clipboard. Wow, now that alone is a huge time saver! This alleviates us from building a URL by the item path and now we can select a URL for different devices as well! The second feature is just as robust. You can now take a URL and paste it into the Search Box above the Content Tree and go directly to the item. No more staring at a URL and drilling down the Content Tree!

Retrieving a URL
Now retrieving a URL is easy, by right clicking the item in the Content Tree we are presented with the Copy Item URL command. By selecting the command it will analyze the item’s presentation details and give you the option to select a URL for any device that is assigned to the items presentation details. For Internet Explorer it will copy the URL directly to your clipboard, for other browsers you have the ability to manually select and copy the text your clipboard. This is due to security issues by these other browsers.

Searching by URL
We are now able to utilize the search box at the top of the Content Tree for searching for an item by its URL. This gives us the ability to quickly and accurately take a url from the website and find it within the Content Manager.

Here at Velir, we are very proud of Daniel’s accomplishments. His outstanding work shows his passion for technology as well as his willingness to help educate others. Daniel’s work has provided an invaluable contribution to Velir and the Sitecore community, most notably in spearheading projects for The Brookings Institution’s Mobile Application, as well as implementing a home grown Learning Management System for The American College of Cardiology. In addition to his involvement in the Sitecore community, Daniel spends his time with his family and as a guitarist in the rock band, Electric Mummy.

Daniel joins a distinguished group of professionals who are some of the most active Sitecore community members around the world, and whose work encourages the objective exchange of knowledge.

“MVPs are technology experts who inspire others to learn and grow through active participation in the Sitecore technical community,” said Lars Floe Nielsen, Senior Vice President, Technical Marketing, Sitecore. “MVPs are not just about evangelizing Sitecore. They are passionate about improving technology and driving innovation and sharing their knowledge and real-world experiences at user groups, on blogs and social channels.”

Sitecore MVPs are chosen by a special panel that considers a professional’s technical expertise and voluntary community involvement over the past year. The panel considers the quality, quantity, and level of impact of the nominees’ contributions, in the areas of general technical advocacy, input via blogs and forums, and content development.

To learn more about Electric Mummy visit electricmummy.com and to download the free song, “I Wanna Live Forever” click here.

Kudos to you, Daniel! Keep rocking!

In Sitecore’s Content Manager, performing actions such as a delete against many items can be very cumbersome. You need to right click each of the items and then click on the Delete menu item individually. This approach works fine when you are deleting one or two items but when you need to delete items in bulk you are losing productivity. The Edit Form is a Sitecore Shared Source Module that provides the content editors with the ability to perform multiple tasks at once, such as copy, cut, and delete. The form allows a user to simply click on multiple items, putting each clicked item in a “Selected” state, shown in the screenshot below. Once one or more items have been selected we can then select a command.

The Edit Form is packaged with three commands, Copy, Cut and Delete, which can all be customized within the Content Manager. For example, you are able to change the sort order of the buttons, delete a button, change the click event for a command to a custom javascript method and even add your own custom command to the Edit Form.

The packaged cut, copy and delete commands make use of the Sitecore pipeline, which means that as the Edit Form’s commands are being executed, they are following the normal process of the respective command in the right click Context Menu. This ensures that custom functionality such as the shared source module the Move Validator that we created earlier in the year will be utilized.

Where can the Module be found? http://trac.sitecore.net/EnhancedTemplateBuilder/

What is the Enhanced Template Builder

The Enhanced Template Builder is a Sitecore Shared Source module that allows the user to easily create and edit templates. It focuses on providing the user with tools and options such as the Field Type Selector, Source Field Builder and the Required Field checkbox that allow for a more efficient and streamlined experience.

Field Type Selector

Selecting a field type can be a confusing process due to the vast amount of field types with similar names and functionality. What ends up happening is you go back and forth between the template and a content item to verify that this is the actual field type you would like to use for that field. Going back and forth from the template to the item may happen several times until the correct field type is selected. On the Enhanced Template Builder form I have added an image button to the right of the Field Type dropdown list.

By clicking on the image button, it will launch the Field Type Selector modal (a screenshot of the modal is below) that consists of two sections. The left side contains a content tree of the field types as specified in the core database. This also includes custom fields that you may have developed. By clicking a field type it will initiate the Preview section on the right which will render the selected field type. By rendering the field, it allows the user to actively use the field as they normally would in the Sitecore Content Editor. If this is the field you would like to use, you can click the Submit button and it will backfill the dropdown list on the Enhanced Template Builder, therefore selecting your field type.

Source Field Builder

The source field is very cumbersome if you wish to do anything more than selecting a root item for that field. You need to know the Sitecore Query language which is confusing and most developers do not use it enough to remember the syntax. Therefore you find yourself consistently going back to older projects or searching the internet for examples that we can modify and make work to the needs of our field. On the Enhanced Template Builder form I have added an image button to the right of the source field and when clicked launches the Source Field Builder.

The Source Field Builder allows the user to select a root node, filter the query based on templates as well as defining whether the query is a deep or not. This greatly increases the efficiency of any developer, reduces research time and allows the developer to focus their attention on more critical areas without having to worry about the proper syntax of a simple or complex query

Required Field

The template builder in its current form does not allow a field to be set as required. To do so, you must leave the template builder and drill down to the field item and set the four fields under the Validation Rules section. This means you need to save your changes, leave the template builder to set the field as required only to most likely return to the template builder to continue building the template. To alleviate this I have added a required checkbox that when saved will auto-populate each of the four fields under Validation Rules with the Required flag.

In Part 2 we’ll be looking at more technical issues such as how we build the API codebase in Visual Studio, the XML and JSON serialization components, and the scenarios our caching strategy covers.

API Architecture

The API we built in Visual Studio can be grouped into two areas: the Model classes and the Sublayouts.

Model Classes

As you likely know, a Model class (sometimes called an Entity Class), contains all the properties that define a single Object. We’ll have a model class for each type of object we want to send back to our mobile apps. For example, there is an Article class, an Expert class, and a Topic class.

These models are then serialized into either JSON or XML. To accomplish the serialization we use features that area already part of the .NET Framework. Namely DataContractSerializer and DataContractJsonSerializer. These two classes rely on Reflection to identify serializable classes and methods using attributes called DataContract (for the class) and DataMember (for the properties).

One common question from folks who use the Custom Item Generator is: why not just use the generated classes as our Models?

A little background on the CIG: The goal of the Custom Item Generator is to facilitate agile development through code generation. Each custom item class is a reflection of the corresponding template found in Sitecore. As changes are made to a template in Sitecore, the custom item file can be regenerated to show the new fields, new base classes, and any field updates.

However the information we send to our mobile apps necessarily needs to be fixed or it would require a client update on the mobile devices. For example, the mobile clients are expecting specific fields with specific names to be passed through via the JSON. The code generation of the custom item generator makes it really easy to rename or remove fields which has the huge impact of breaking the data contract between Sitecore and the mobile devices. So we keep these model classes to expose just the data that is need for the mobile apps in an easily serializable way as well as for maintaining that data contract. There are other ways to accomplish the same goal, (maybe a Mobile API Interface), this way worked well for us.

Layouts and Sublayouts

The Mobile API layout and sublayouts, as we saw, are plugged into the Mobile API Device. For our case, we know we’re going to be returning something more data oriented like JSON or XML so we don’t need much in presentation. Therefore our Layout file is very simple and only contains a Placeholder for the Sublayout.

For the Sublayouts, there is one for each request type. In our example we’ll be looking at segments from the Article sublayout. Each sublayout has a couple common responsibilites: they should a) populate the equivalent Model Class, and b) issue the JSON/XML Response. For issuing the Response, let’s look at the following segment:

This snippet deserves a little discussion because it has some elements we haven’t talked about yet. First, our mobile apps have the option of including a date with the request representing the last time that mobile app issued that request. The idea is that if the mobile app has issued that request before and the content on the server hasn’t changed, then the mobile app is allowed to use its local cache. Let’s explain:

In the first condition, if there is no date (LastFetchValue == null) or if the date is more recent than the last time the content was updated (represented as ‘mostRecentUpdateUtc’), then we will execute the serialization normally and return that in the response.

However, if there was a date, and it is more recent than the last time the content was updated, then we have the opportunity for some performance gains. We will skip the serialization (gain 1); return something very small, a “Not Modified” response code (gain 2); which then tells the mobile app to use its local cache (gain 3).

Base Class: ApiResponder

Because the goals of each Sublayout are similar, there is a benefit to having each sublayout inherit from a base class which can implement common actions. Our base class is called ApiResponder. This baseclass shares its implementation with the Sublayouts for the following two areas: a) execution of the JSON/XML Serialization and b) cache management (which we haven’t talked much about yet). The following is a segment from ApiResponder that handles the serialization:

In this code snippet we’re calling the appropriate DataContract method depending on which serialization format has been requested.

Caching Strategy

We’ve identified so far that there is a caching strategy involved. Let’s look more closely at what this means. First, some of the benefits we’ll gain from using caching:

• When we use a caching strategy it can result in fewer round trips to the server
• This implies less load on the server which increases scalability
• We gain faster page loads when using the local cache
• This implies a better user experience.

Local Cache DB

A local cache on a mobile device can be something as straightforward as a database record. Take this example which is essentially what we need: The record contains:

• The URL which for our RESTful API is the equivalent of the web method call.
• The Response: which for our app will contain the raw JSON/XML from the initial request
• The Date: this is what we use to record the date/time our response data was collected from the server.

Next, let’s look at the logic behind how we will use our cache. This somewhat complex looking Cache State Diagram can be summarized in 4 basic use cases. But first to understand it we need to introduce the concept of the cache trust period. That is to say, suppose our period is 20 minutes, then our mobile app will trust the local cache for 20 minutes. Any requests for something in the cache that is older than 20 minutes is considered stale, requiring a request to Sitecore.

Use Cases

#1: The user requests from the mobile app an Expert page for the first time.

Because it’s the first request, there will not be a record in the local cache. Our flow will go to Sitecore. Because there is no date in our request, Sitecore will issue a serialized response of the Expert item. Our mobile app will store that response data in the cache table and render the view.

#2: The user requests the same Expert page 10 minutes later.

The response data will already be in our cache db, and because it is only 10 minutes old, it is under our 20 minute threshold. We can use the local cache and avoid reaching out to Sitecore entirely. Because we didn’t check with Sitecore we will not modify the date already in our cache record.

#3: The user requests the same Expert page 20 minutes later.

We are now 30 minutes after our initial request, or 10 minutes beyond our threshold. So the response data will be found in our cache table, but it is considered stale. Therefore we issue a request to Sitecore. In this use case, let’s assume that nothing has changed on this expert page within the last 30 minutes. Sitecore will now bypass the serialization and instead issue a 304 code as the result. Our mobile app, when receiving the 304 code, knows to use the local cache. And because we did confirm this content with Sitecore we will modify the date on our cache record.

#4: The user requests the same Expert page 30 minutes later.

Again, we are 10 minutes past our threshold for determining if our local cache is stale. Similar to use case #3 we will send our request to Sitecore. This time, let’s say that something did change on this Expert page within the last 30 minutes. Therefore Sitecore will execute the serialization and return that in the response. Our mobile app will update the local cache record with the latest data and a new date, and render the view to the user.

If you followed along, we covered each state represented in the diagram. Cool! We’ve also now described and implemented a very robust caching system that will improve the user experience, and decrease the server load.

Sitecore Publishing Strategies

Hiding Pages from Mobile Devices

There are some mechanics we can provide to make managing mobile content easier for content authors. One example is suppose our website has pages that are great for a desktop web browser but are less friendly for mobile devices. I’m looking at you, Mr. Flash Media Player. A simple checkbox in the Sitecore template can address this for the content author’s experience. And in the back end, we’ll want to implement code to ensure these pages are not discoverable on mobile apps.

Hiding Content from Mobile Devices

Or, if we want the page to be discoverable on mobile apps, but perhaps there is something on the page from a Rich Text Editor that isn’t going to render well, that can be addressed too. In this case we added a button to the Rich Text interface which inserts a not-mobile tag. In the codebase we add a Mobile Tag Resolver class which goes into the Rich Text pipeline. This class is responsible for removing the not-mobile wrapped content prior to serialization. Additionally there is a message attribute. Our content authors can add text here which the viewer would see instead of the original content. Something like, “This table has been removed from the mobile view. Please view this page on a desktop/laptop to see the table.”

In addition to flash content, examples of things that may be removed include large images and complex table layouts.

Additional Strategies to Consider

Identify a target OS and Feature set

In contrast to simply building a Blackberry app, identify the minimum version and OS that this app will support. It will greatly simplify the requirements and codebase when there isn’t a need to support every possible scenario. The further back we go, the harder it is to maintain, obviously. Take for example a web application that is required to support IE6 vs one that only needs to provide support for IE7/8. Enough said.

Render images asynchronously

Note that in our JSON/XML we are not passing the images themselves, but rather we are passing the location of the image. This means that we’re still going to need to get those images. A good strategy here is to go ahead and load as much of the view as possible, while in the background retrieve and load in the images asynchronously. The benefits of getting the user to their content as fast as possible goes without saying, and this one way to improve the user experience.

Keep the user within the app for internal links

In rich text content, authors have the flexibility to add both external links to pages out in the webiverse and internal links to other Sitecore based content. If our mobile app supports internally linked content, such as Article and Expert pages, then the worst thing to happen would be to have the user click that link and see it opened in the mobile device’s browser. Ideally what we want is to keep the user inside the context of the mobile app. Our method here was to append api=1 to the end of internal URLs prior to returning the response. This will be the indicator our mobile app uses to keep the rendering with the mobile app.

Recap

There are a number of different strategies we looked at to conceptualize the Mobile App integration with Sitecore.

RESTful API: We looked at the specifics of what it means to be RESTful as well as relating this to design patterns and their benefits.

Sitecore Configuration: We looked at how Sitecore was configured using standard Sitecore features in order to facilitate the use of the RESTful API concepts and coordinate the codebase.

The Code: We looked first at Model classes which would become serialized and represent our response data. And we looked at the Sublayouts and their shared base class, the API Responder which was responsible for populating the Models, executing the serialization, and managing the cache.

References

RESTful API

http://www.freshblurbs.com/pragmatic-restful-api-design

https://www.ibm.com/developerworks/webservices/library/ws-restful/

http://en.wikipedia.org/wiki/Representational_State_Transfer

DataContract Serialization

http://msdn.microsoft.com/en-us/library/ms733127.aspx

At a high level, the requirements included:

• Sitecore continues to be the single source of content.
• The Mobile API is to be built using the Sitecore API and the custom .NET code that already powers the website
• The Mobile API needs to be device agnostic. We’re originally targeting clients that will be built in Object C (IPhone) and Java (Android/Blackberry)

One of the great things about Sitecore, and ideally why we would want to use any CMS, is the ability to maintain our content in a single environment, then to reuse that content in a variety of environments and mediums including Web, RSS, Newsletters, Print Media, Social Media, and this article’s topic: Mobile Applications.

Restful API

The foundation for building this API was to prescribe to the RESTful pattern. This can be thought of as a Design Pattern for building reusable APIs. Some important aspects of Design Patterns in general include:

• Shared common language between developers. (If I use Design Pattern “A” and the next developer knows Design Pattern “A”, then there will be certain constructs and vocabularies that are assumed. Essentially we both speak the same language)
• A Design Pattern is a structure that has been found acceptable for solving a particular problem.
• A Design Pattern is robust; it has withstood the test of time and analysis.

As a Design Pattern, building a Restful API fits in well with our goals as many of its tenents will be beneficial to us. Some of the key tenents that we are interested in include:

• Stateless: Our Mobile Apps will not be reliant on session data, a simple request and response is all that his required.
• JSON/XML: The response should be an abstraction of the data that is easily consumed.
• HTTP Methods: Also called verbs, the RESTful web methods should use GET/POST/PUT/DELETE as intended. For example, calling GET should only retrieve information. It shouldn’t be used to create or delete records.
• Directory Based URIs: With RESTful, the directory and filename is the API call. This fits in very well with Sitecore since Sitecore’s URI structure already mirrors the content tree.

Configuring Sitecore

We’ll be looking at a few places where we configure Sitecore to support the RESTful API. This part is straightforward and proves to be a natural fit within Sitecore which is a big win. It includes the Device Configuration, Presentation/Sublayouts, and the Content Tree structure.

Device Configuration

Since browser requests look exactly the same as RESTful requests, we need a way to distinguish when our Mobile App is issuing the request. RESTful recommends using the ACCEPT header which can then ask for JSON or XML instead of the usual HTML. However in Sitecore what we really want to do is to call a different sublayout which will be responsible for returning JSON/XML instead of HTML. Sitecore makes it easy to do by using the Device Configurations. Here we can identify our device one of two ways, either by User-Agent or by Query Param. We decided to use the query param “api=1″. Thus when Sitecore sees the param it can switch to the sublayouts we’ve specified for handling Mobile API requests.

Presentation Settings

The Default Device in Sitecore generally contains layouts/sublayouts that are used for the HTML rendering of the website. Now that we have a MobileAPI Device we can use this to similarly store the layout/sublayouts we want to use to handle our API Request. In the following picture we focus in on the MobileAPI devices’ layout and sublayout for an Article page.



In the following two screens we should the difference between a page rendered with the Default Device, which returns HTML, and a page rendered with the MobileAPI Device, which returns JSON.





Content Tree Design

As mentioned earlier, the synergy between the way that Sitecore constructs URLs from the Content Tree path and the RESTful API approach to web method calls is important. If we want to retrieve a list of all Experts for example, we would issue a request to the node representing the Experts folder such as: http://www.rilev.edu/experts.aspx

However if we wanted an individual Expert, the method call would extend upon this path to include the specific Expert. For Example:

http://www.rilev.edu/experts/ddelay.aspx

(Note that the /a/ has been stripped from the request. The /a/ is important in the Sitecore content tree for organizational and performance purposes. It is okay to keep this in the request, but isn’t required. So for simplicity and readability, we remove this by adding a custom ItemResolver class to the pipeline in Sitecore.)



This is it for Part 1. In Part 2 of this blog post we’ll delve deeply into several technical topics such as the API Architecture, Caching Strategy & Use Cases.

Lazy Loading is a design pattern that is used to defer the loading of information or content until it is needed. This pattern has several implementations that can be used to improve the performance of websites and applications. The method we will focus on is called Lazy Initialization, in this pattern content will not be loaded until you actually need it. If you have any sort of click navigation, or rotating features, or AJAX style design features, then it could become very easy for you to render content only when content is needed. Let’s look at the workflow of a lazy loading solution and what it actually does to provide us with this benefit.

We will implement our lazy loading using JQuery AJAX and .NET Webservices. On the client side, we use JQuery to create content control objects that will make an AJAX style call to an ASP.NET Webservice. This will perform the calculations and content fetching and return the required data in a JSON format. The data is then processed through JTemplate to produce the output.

Client calls out to a .NET Webservice and request a list of items from Sitecore. Then it will process the results from this request and compile that information into a JSON return object.

The following code shows an example of a JavaScript/JQuery object that includes an AJAX method for data retrieval.

this.sendRequest = function (url, postData) {
			var data = { "scriptPostData": postData };
			$.ajax({
				type: 'POST',
				url: url,
				contentType: "application/json; charset=utf-8",
				dataType: 'json',
				data: JSON.stringify(data),
				success: this.cfg.OnDataSuccess
			});
		};

The config value for OnDataSuccess is a callback method inside the Javascript object that is used to display the return results. For example, you can use a method that takes the data in the return object and displays the information using a template plugin like JTemplate. For example:

this.DefaultProcessData = function (response) {
			var items = { items: response.d.ContentItems };
			var cfg = JSON.parse(this.data);
			var contentArea = jQuery(cfg.scriptPostData.PlaceholderSelector);
			var oldHtml = contentArea.html();
			contentArea.setTemplateURL(cfg.scriptPostData.TemplateUrl, null, { filter_data: false });
			contentArea.processTemplate(items);
			contentArea.prepend(oldHtml);
}

This type of implementation is used in a “Load More” scenario where the list renders the first (say 5) content objects. When the client clicks a button, it fires off a request to the content control object that uses a webservice to pull the next set of information. Next we will take a look at the ASP.NET Webservice’s side of Lazy Loading.

If you are not familiar with the process of creating a Webservice in Visual Studio, then take a look at this MSDN article. After creating the webservice it should look something like this:

There is one additional thing requirement that is needed in the Webservice to allow JQuery to make the call. You will need to uncomment the class decoration for [ScriptService].

Now its time to implement your own Webmethod to process the request from the AJAX call. To make things easier, you should first implement 2 data contracts. The first data contract will represent the values being sent to the Webservice from the AJAX JSON POST request, while the second data contract will represent the return value. This return value will be converted to a JSON string that can then be parsed and used in the return method. Here is how we create the classes inline with the Webservice code:

Now that we have the data contracts, we can access the information that the JQuery AJAX call is sending to us, and the JQuery return method will be able to understand our responses. Our new WebMethod looks like this:

The GetContent method retrieves the Content Item objects and then inserts them into the Return Content object. The return object is then serialized into a JSON string (which is handled by ASP.NET behind the scenes so there’s no need to worry about this part) and then sent back to the AJAX request call. Finally, when the AJAX call receives the data it fires off the OnDataSuccess callback method to handle and process the return results.

That’s all there is to creating and using the Lazy Initialization pattern using JQuery and ASP.NET Webservices. In our testing we have seen pages that would have taken up to 20 to 30 seconds to load, but by using Lazy Loading they have been reduced to roughly 500 milliseconds. I would consider this to be a mission accomplished and would say that here is proof that it pays to be Lazy!

Here are a couple of notes to consider before implementing this yourself.

1.) The Request type for the JQuery AJAX call *must* be POST. Because of this, you can forget about using services to cache the response from the request. Instead, use localized caching methods to speed up requests. For instance, we make our cache key named based on values of input to the GetContent webmethod. Applying this method will greatly reduce the load on your servers when users send the request to load more content. This is what our cache key looks like.

We then use a cache object to insert / retrieve values of the cache based on this key.

2.) You can implement the “GetContent” method with any signature you like, but he data you pass to it from the JQuery must match the signature. So in this case you see that the JQuery sends in the post data a JSON stringafied object that within it contains a variable “scriptPostData” which matches up to the name of the variable in the signature of the WebMethod. While you don’t need to use a single object for the information you pass to the Webservice, it is much easier to use this PostData object, than it is to list out 10+ variables in the WebMethod signature.

To read more about the other types of Lazy Loading (Virtual Proxy, Virtual Holder, and Ghost), please see the Lazy Loading article on Wikipedia.

• Experience writing C# code.
• The ability to use delegates already. Maybe you just don’t use them often or are not sure how utilize them effectively. Knowing how to use delegates will be important as I don’t cover this. I recommend reading the MSDN documentation on them if you don’t already have experience with them.
• Intermediate programming experience. I’ll be using some programming jargon that will seem foreign to novice programmers. If you’re a novice but consider yourself up to the challenge, feel free to continue with the tutorial as you too will certainly get something out of it.

Why Delegates?

public class ListProcessor
{
        public static List<string> ProcessList(List<string> strings)
        {
                List newList = new List();
                foreach (string str in strings)
                {
                        newList.Add(ProcessItem(str));
                }
                return newList;
        }

        private string ProcessItem(string str)
        {
                return str.Replace("a", "b");
        }
}

public class ListProcessor
{
        public delegate string StringProcessor(string str);

        public static List<string> ProcessList(
                        List<string> strings,
                        StringProcessor processor)
        {
                List newList = new List();
                foreach (string str in strings)
                {
                        newList.Add(processor(str));
                }
                return newList;
        }
}

ListProcessor.ProcessList(
        myListOfStrings,
        str => str.Replace("a", "b"));

public class ListProcessor
{
        public delegate bool StringAcceptor(string str);

        public delegate string StringProcessor(string str);

        public static List<string> ProcessList(
                        List<string> strings,
                        StringAcceptor acceptor,
                        StringProcessor processor)
        {
                List<string> newList = new List<string>();
                foreach (string str in strings)
                {
                        if (!acceptor(str))
                        {
                                continue;
                        }
                        newList.Add(processor(str));
                }
                return newList;
        }
}

ListProcessor.ProcessList(
        myListOfStrings,
        str => !str.Contains("c"),
        str => str.Replace("a", "b"));

Let’s Go Further With Generics

public class ListProcessor
{
        // This is equivalent to the built-in Predicate delegate
        // http://msdn.microsoft.com/en-us/library/bfcke1bz.aspx
        public delegate bool Acceptor<in TA>(TA obj);

        public delegate TB Processor<in TA, out TB>(TA obj);

        public static List<TB> ProcessList(
                        List<TA> objects,
                        Acceptor<TA> acceptor,
                        Processor<TA, TB> processor)
        {
                List<TB> newList = new List<TB>();
                foreach (TA obj in objects)
                {
                        if (!acceptor(obj))
                        {
                                continue;
                        }
                        newList.Add(processor(obj));
                }
                return newList;
        }
}

List<string> resultStrings = ListProcessor.ProcessList(
        myListOfStrings,
        str => !str.Contains("c"),
        str => str.Replace("a", "b"));

List<Uri> resultUris = ListProcessor.ProcessList(
        myListOfStrings,
        str => !str.Contains("amikawaiiuguu.com"),
        str => new Uri(str));

List<Uri> resultUris = myListOfStrings.
        Where(str => !str.Contains("amikawaiiuguu.com")).
        Select(str => new Uri(str)).ToList();

public class DatabaseRecord
{
        public delegate bool RecordCallback<in T>(T record)
                where T : DatabaseRecord;

        // Returns true if the record is saved.
        public static bool SaveRecord(DatabaseRecord dbr)
        {
                // Saves the record
                // Assume this is implemented
        }

        // Returns false if the pre or post validation fail, or if the saving fails.
        // Returns true otherwise.
        public static bool SaveRecordWithValidation<T>(
                        T record,
                        RecordCallback<T> onPreSave,
                        RecordCallback<T> onPostSave)
                                where T : DatabaseRecord
        {
                return  onPreSave(record) &&
                        SaveRecord(record) &&
                        onPostSave(record);
        }
}

Case in Point

Creating Your Own Validator

To create your own validator you will need to create a new class and inherit from the Validator base class (ItemComparer.Library.Validations.Validator). The base class contains the correct signature and parameters that the Item Comparer will call and pass during its validation process. I’ve included a quick example below which checks to make sure an item exists in the target database.

    public class ExampleValidator : Validator
    {
        public override List Validate(ItemComparerContext context)
        {
            //default list
            List outputs = new List();

            //check to see if the item exists in the target database which
            //was specified in the settings item
            Item publishedItem = context.TargetDatabase.GetItem(context.Item.ID);
            if (publishedItem == null)
            {
                outputs.Add("The item does not exist in the target database.");
            }

            return outputs;
        }
    }

Adding your Validator to the Published Item Comparer

The Item Comparer’s validators are managed within a configuration file. This gives us the flexibility to add, remove, and even position the order in which they run in. Positioning is important due to the fact that when the Item Comparer does its initial check against an item in the content tree, it stops when the first validation fails and outputs its result in the ribbon. Therefore its beneficial to have the less intensive, core validators run first. Once your Validator class is complete, you will need to add a line in the ItemComparer.config file (located: /App_Config/Include/ItemComparer.config). This will tell the Item Comparer to run the new validation during its process. If you needed to remove a Validator you only need to comment or remove that validation from the configuration file.

Item Comparer Context Object

Each validation class implements a member called Validate which takes in the ItemComparerContext object. This object gives you direct access to a few useful objects and was meant to decrease the amount of redundant lookups within each validator class.

    public class ItemComparerContext
    {
        public Item Item { get; set; }
        public ItemComparerSettingsItem ItemComparerSettingsItem { get; set; }
        public Database TargetDatabase { get; set; }
    }

Ending Note
Over the last couple months, Velir has added this module to several of our projects including a few of my own. My co-workers, clients and I are finding ourselves increasingly using this tool. One of the main reasons for the success of this module is we are able to add custom validations on a per project basis depending on that project’s needs.

I look forward to any comments or feedback regarding the module and I hope it has made it a little easier to compare an item between databases.
Thanks!
Tim