This is part 2 of a series on KiGG Automation.

Part 1: Automating KiGG Publishing
Part 2: KiGG’s Story Summary 
Part 3: Automating KiGG Submission

I noticed that sometimes when you submit a story to KiGG, the summary of the story looks rather garbled. Wishing to correct this, I explored what is actually happening when KiGG summarizes a url for you.

The first step in the process is to go to the submit new story page. When you enter a url into the url field, the site will perform an ajax call that suggests a title and summary. This call is defined by _urlChanged() in story.js. The ajax call is to /Retrieve. Here is the relevant code from New.aspx.

if (Model.AutoDiscover)
{
    scriptManager.RegisterOnReady("Story.set_retrieveStoryUrl('{0}');"
        .FormatWith(Url.RouteUrl("Retrieve")));
}

This will only work if AutoDiscover is set to true, and that is defined in the web.config.

After looking at our routes, we can tell that /Retrieve is calling the Retrieve method on the StoryController. It then returns a view with a StoryContent object after calling the Get method on the member _contentService. This member is set in the constructor. Since KiGG uses Unity, we will need to follow the trail in the web.config to determine which IContentService it’s using (or you can view all classes that implement IContentService and infer the correct choice).

Looking in the web.config, we find the tag: <type type=”StoryController”>. Within the constructor element, we find that contentService is defined as IContentService. Looking through the type elements, we discover that there are three IContentService types. Two of these are decorators (Logging and Caching), so the functionality we’re looking for must be in the one named Base. It maps to ContentService, which is defined in the typeAlias section as Kigg.Infrastructure.ContentService, Kigg.Core. The cool thing about Unity is that you can add your own ContentService decorators and use the web.config to decorate the class without changing any source code.

The content service retrieves the html from the url provided, then calls the converter (again defined by Unity).

string html = 
    _httpForm.Get(new HttpFormGetRequest{ Url = url }).Response;

return string.IsNullOrEmpty(html) ? 
    StoryContent.Empty : _converter.Convert(url, html);

The converter maps to HtmlToStoryContentConverter. Inside that class is the code that attempts to find the content.

private Node TryToFindContentNode(Node bodyNode)
{
    Node contentNode = null;

    foreach (string xPath in _xPaths)
    {
        contentNode = bodyNode.SelectSingleNode(xPath);

        if (contentNode != null)
        {
            break;
        }
    }

    return contentNode;
}

_xPaths is passed in a constructor which is called by another constructor which reads a file. Inside the web.config, we find that Unity has defined the location of the file.

<param name="fileName" parameterType="System.String">
    <value type="System.String" value="App_Data/contentNodes.txt"/>
</param>

Our content nodes are defined within App_Data/contentNodes.txt file. Using this file, we can add xpath style declarations to properly retrieve content from nonstandard articles. Further logic (ignoring h1s, etc) will require changes to the ContentService itself.