However we do realize Razor for Umbraco has its flaws. It is not exactly the Razor view engine we have learned to use in ASP.NET MVC and we need to be careful with LINQ or lambda expressions as not all of the features perform equally well. Over time we learned the dos and don’ts but it did involve some trial and error and it had us fix performance issues on several occasions.

Page level caching                         

The document templates we create in Umbraco often contain multiple (Razor) macros that fetch common data or iterate common nodes or node trees. Having these types of operations perform separately in each macro comes with a performance penalty (especially for expensive operations) and that is why we cache commonly accessed data and nodes on page level.

As the templates are still running on top of ASP.NET web forms we figured a good place to cache these operations is in the page items collection. Of course we could also have used a different cache object and the built-in MVC features of Umbraco 4.10+ will probably have us review this implementation as soon as we start using it (which is hopefully very soon ;-))

    public abstract class PageCache
    {
        protected abstract T GetPageItem<T>(string key, Func<T> objectRetrieval);
    }

    public class WebFormsPageCache : PageCache
    {
        protected override T GetPageItem<T>(string key, Func<T> objectRetrieval)
        {
            var page = HttpContext.Current.Handler as Page;
            if (page.Items[key] == null)
            {
                page.Items[key] = objectRetrieval();
            }
            return (T)page.Items[key];
        }
    }

By first creating a “master” page cache we can cache operations that will probably be used throughout the entire website, such as accessing the root node or a data repository query that is often used.

    public class MasterPageCache : WebFormsPageCache
    {
        public DynamicNode DataNode
        {
            get
            {
                return GetPageItem<DynamicNode>("DataNode", delegate
                {
                    return new DynamicNode(Node.getCurrentNodeId()).AncestorOrSelf(1)
                        .ChildrenAsList.First(y => y.NodeTypeAlias == "DataContainer");
                });
            }
        }

        public EventList ActiveEventList
        {
            get
            {
                return GetPageItem<EventList>("ActiveEventList", delegate
                {
                    return new EventRepository().GetActiveEventList();
                });
            }
        }
    }

The page cache for a specific template or document type inherits from the master page cache allowing it to further extend any of the master cache operations.

    public class HomePageCache : MasterPageCache
    {
        public DynamicNode HomeHeaderCarousel
        {
            get
            {
                return GetPageItem<DynamicNode>("HomeHeaderCarousel", delegate
                {
                    return DataNode.ChildrenAsList.First(n => n.NodeTypeAlias == "HomeHeaderCarousel");
                });
            }
        }

        public List<DynamicNode> HomeHeaderCarouselSelectedEvents
        {
            get
            {
                return GetPageItem<List<DynamicNode>>("HomeHeaderCarouselSelectedEvents", delegate
                {
                    return HomeHeaderCarousel.ChildrenAsList.Items
                            .Where(i => ActiveEventList.Items.Count(e => e.Id == i.GetPropertyValue("eventId")) > 0)
                            .ToList();
                });
            }
        }
    }

Finally we can new up a page cache in a macro, and we are rest assured that the cached operations will only execute once (provided of course that other macros on the page also use a page cache).

@using System.Xml.Linq;
@using TheseDays.Sportsbetting.Business.Events;
@using TheseDays.Sportsbetting.Business.Web;
@using TheseDays.Sportsbetting.UserControls.Helpers;
@using umbraco.MacroEngines;

@{
    var pageCache = new HomePageCache();
    var maxEvents = 5;
}

@if (pageCache.HomeHeaderCarouselSelectedEvents.Count() > 0)
{
    foreach (var item in pageCache.HomeHeaderCarouselSelectedEvents.Take(maxEvents))
    {
        var imagePath = XDocument.Parse(item.GetPropertyValue("image")).Descendants("umbracoFile").First().Value;
        var eventItem = pageCache.ActiveEventList.Items.First(i => i.Id == item.GetPropertyValue("eventId"));

        <div>
            <img id="item-@item.Id" src="/ImageGen.ashx?width=@imgWidth&image=@imagePath" />
            @eventItem.Time.ToShortDateString() @eventItem.Time.ToShortTimeString() @eventItem.HomeTeamShort - @eventItem.AwayTeamShort
        </div>
    }
}

Resolving a page cache dynamically

Most of the time page caches relate directly to a document type so we figured it would be cool if we could just have a page cache “magically” resolved based on that document type rather than having to new up a page cache in each macro. The Razor engine provides us with a model which has a reference to the document type and basically we would like to do something like this:

@{
    var pageCache = UmbracoPageCache.Resolve(Model.NodeTypeAlias);
}

Even though I am not too keen on using reflection and dynamic types in .NET with some experimenting I did manage to come up with a solution which is based on a very simple naming convention. A page cache is resolved when its class name starts with the node type alias of the document type. If no page cache could be resolved, a fall back will try to resolve the master page cache of which the class name should start with “Master”. This is nice if you don’t have a specific page cache setup but if you would still like to use some of the master cache operations.

Although it is still a bit experimental, the code snippets below show how it can be done. Note that the code uses an assembly filter which limits the assembly lookup to assemblies marked with company name “TheseDays”.

Feel free to use or extend the code or to post any feedback or remarks. Cheers!

    public abstract class PageCacheResolver
    {
        protected TypeLocator _typeLocator;
        protected AssemblyFilter _assemblyFilter;
        protected Assembly _pageCacheAssembly;

        public PageCacheResolver(AssemblyFilter assemblyFilter)
            :this(assemblyFilter, new TypeLocator())
        {
        }

        public PageCacheResolver(AssemblyFilter assemblyFilter, TypeLocator typeLocator)
        {
            _assemblyFilter = assemblyFilter;
            _typeLocator = typeLocator;

            ResolvePageCacheAssembly();
        }

        protected virtual void ResolvePageCacheAssembly()
        {
            _pageCacheAssembly = new AssemblyLocator(_assemblyFilter)
                .FindAssembliesContainingSubclassesOf<PageCache>().First();
        }

        protected virtual dynamic ResolveByPrefix(string prefix)
        {
            if (String.IsNullOrEmpty(prefix))
                throw new ArgumentException("prefix");

            var cacheType = _typeLocator.FindSubclassesOf<PageCache>(_pageCacheAssembly)
                        .Where(t => t.Name.ToLower().StartsWith(prefix.ToLower()))
                        .FirstOrDefault();

            if (cacheType != null)
            {
                return _pageCacheAssembly.CreateInstance(cacheType.FullName);
            }
            else
            {
                return null;
            }
        }
    }

    public sealed class UmbracoPageCache : PageCacheResolver
    {
        private UmbracoPageCache(AssemblyFilter assemblyFilter)
            :base(assemblyFilter)
        {
        }

        public static dynamic Resolve(string nodeTypeAlias)
        {
            var assemblyFilter = new AssemblyFilter();
            assemblyFilter.CustomAttributes.Add(new AssemblyCompanyAttribute("TheseDays"));
            var resolver = new UmbracoPageCache(assemblyFilter);

            var cache = resolver.ResolveByPrefix(nodeTypeAlias);
            if (cache != null)
            {
                return cache;
            }
            else
            {
                throw new ApplicationException("Unable to resolve cache");
            }
        }

        protected override dynamic ResolveByPrefix(string prefix)
        {
            var cache = base.ResolveByPrefix(prefix);

            if (cache != null)
            {
                return cache;
            }
            else
            {
                // Fallback to master cache
                return base.ResolveByPrefix("master");
            }
        }
    }

Helpers classes for reflection:

    public class TypeLocator
    {
        public IEnumerable<Type> FindSubclassesOf<T>(Assembly assembly)
        {
            var result = from t in assembly.GetTypes()
                         where t.IsSubclassOf(typeof(T))
                         select t;
            return result;
        }
    }

    public class AssemblyFilter
    {
        public List<Attribute> CustomAttributes;

        public static AssemblyFilter DefaultFilter
        {
            get { return new AssemblyFilter(); }
        }

        public AssemblyFilter()
        {
            CustomAttributes = new List<Attribute>();
        }
    }

    public class AssemblyLocator
    {
        protected AssemblyFilter _filter;

        public AssemblyLocator(AssemblyFilter filter)
        {
            _filter = filter;
        }

        public AssemblyLocator()
            : this(AssemblyFilter.DefaultFilter)
        {
        }

        protected IEnumerable<Assembly> GetFilteredAssemblies()
        {
            IEnumerable<Assembly> result = AppDomain.CurrentDomain.GetAssemblies();

            if (_filter.CustomAttributes.Count() > 0)
            {
                result = result.Where(a => _filter.CustomAttributes
                    .All(attr => a.GetCustomAttributes<Attribute>().Contains(attr)));
            }

            return result;
        }

        public IEnumerable<Assembly> FindAssembliesContainingSubclassesOf<T>()
        {
            foreach (var assembly in GetFilteredAssemblies())
            {
                var result = from t in assembly.GetTypes()
                             where t.IsSubclassOf(typeof(T))
                             select t;
                if (result.Count() > 0)
                {
                    yield return assembly;
                }
            }
        }
    }

And a very basic unit test:

    [TestClass]
    public class UmbracoPageCacheShould
    {
        [TestMethod]
        public void ResolveDocumentTypePageCacheIfOneExists()
        {
            var col = UmbracoPageCache.Resolve("DocumentType");
            Assert.IsInstanceOfType(col, typeof(DocumentTypePageCache));
        }

        [TestMethod]
        public void ResolveMasterPageCacheIfDocumentTypePageCacheIsMissing()
        {
            var col = UmbracoPageCache.Resolve("Bullocks");
            Assert.IsInstanceOfType(col, typeof(MasterPageCache));
        }
    }

    public class MasterPageCache : WebFormsPageCache
    {
    }

    public class DocumentTypePageCache : WebFormsPageCache
    {
    }

The demo covering the fundamentals however became quite large as I ended up refactoring it a dozen of times, by introducing abstractions and adding design patterns on the fly. Although I must admit a certain degree of complexity was added to its design, the demo does cover a lot of OO practices and design patterns and it really shows how a good design adds to reusability, flexibility and extensibility.

That is why I decided to share the demo code on github and cover its design in this blog post. The application was written in C#.NET and created in Visual Studio 2010, but of course any of the design patterns discussed can be applied in any other OO programming language.

What the application does

The demo’s functionality is actually very limited. When it launches, a random story is generated and shown in a console window. As you can see in the snapshot below a story unfolds at a market: the market starts, people arrive and tend to their business – salesmen sell their goods and customers shop for the items they need. Eventually the salesmen close their stalls and the market closes, end of story.

A first glance at the code

The Visual Studio solution consists of 3 projects which (kind of) demonstrate an N-layer approach:

• Data – A class library representing the data layer which has not been implemented (yet)
• Marketplace – A class library representing the middle/business layer
• Program – A console application representing the presentation/GUI layer

As shown in the code editor below the console application is initiated in the program’s Main method, which only contains a few statements that create a story. But of course, all of the magic really takes place in the Marketplace project ;-)

Abstractions, abstractions, abstractions

Since I wanted to cover OO fundamentals such as inheritance, interfaces and polymorphism the first thing you will notice is that the code in the Marketplace class library is bloated with abstractions. There are several abstract base classes, a shitload of interfaces (when you consider the size of the application) and also the state broadcasting mechanism is completely abstracted out by event handling/subscription.

Another thing you may notice is that the class library’s overall structure (i.e. namespaces) is not as informative as it should be as I organized the classes in order of their appearance during the demo. Just to give you a better idea I had Visual Studio generate a class diagram which I then quickly organized manually (click to enlarge).

Extensibility is king

The Marketplace project contains most if not all of the abstractions and building blocks and it also provides several concrete classes that allow for a quick implementation of a market story in the GUI project (Program).

The GUI project then introduces a series of new concrete subclasses that demonstrate the extensibility of the class library by adding new functionality or by extending existing functionality, in a variety of ways. Let’s have a look at the source code and identify the design patterns that were used.

Template Method

At the center of the class library an abstract class Story exists which follows the template method pattern allowing its child types to override a series of methods that are executed sequentially when the story’s Play method is called.

• Initialize – Allows the story to perform a setup routine (i.e. instantiating the objects it requires)
• AttachListeners – Allows the story to subscribe its event listeners to any of the state notifiers that will broadcast their state changes when the story is running. The default implementation will attach a default event listener if none were attached and it will also subscribe its event listeners to itself (the story itself can also broadcast state changes)
• Run – Allows for the actual implementation of the story. The default implementation provides a loop that adheres to the story settings (start & end date/time and the interval) and it introduces a fourth template method RunStoryLine
• RunStoryLine – Allows the story to implement the code for a single story line

As formulated by the open/closed principle the template method approach allows for a very granular implementation within child types. The MarketStory class for example extends the Initialize and AttachListeners methods (using the default implementation as well as adding its own implementation) whereas it completely replaces the implementation of the Run and RunStoryLine methods.

The GUI project introduces the LorumIpsumStory class which demonstrates just how little code it takes to implement a (simple) story. Changing the Program’s Main method by creating an instance of LorumIpsumStory, a different story is generated much like the one shown in the snapshot below.

Factory

Following the single responsibility principle had me refactor the application on several occasions and most violations against this principle seemed to occur in the MarketStory class as it just had way too many responsibilities. One of the things I ended up abstracting out is the instantiation of the market object which takes place in the Initialize method.

The factory pattern encourages moving the implementation required for object instantiation into a separate class as this process can introduce extra dependencies. The CreateMarket method of the RandomMarketFactory shows that instantiating a market object involves fetching data from a repository and adhering to a list of creational settings. Having this implementation and its dependencies removed from the MarketStory class into a factory class was just the next logical step in the refactoring process.

Factory method

Instead of introducing a factory class, another way of dealing with object instantiation is by moving this responsibility to the class itself. Instances of the StorySettings class for example are created by passing several values into its constructor.

If you would like to create an instance of StorySettings with values that are stored within a configuration file for example you would need to read the file, fetch the values and then instantiate an object with these values. To ease this process the StorySettings class provides a factory method FromConfiguration that will instantly instantiate an object with values read from a configuration file.

Note that this practice should be used with caution as it may result in dependencies that are hard to overcome, for example the dependency between StorySettings and the .NET configuration manager as well as any dependencies to the instantiated object itself.

Dependency injection

Having dependencies that are needed for object instantiation moved into a factory class is beneficial, but it also introduces a new dependency. For the MarketStory to be functional it now requires an instance that implements MarketFactory. As this dependency cannot be removed the next best thing one can do is to be very explicit about it and have the dependency “injected” either via its constructor or via a property. I prefer using constructor injection over property injection because I find it to be more visible.

This practice is commonly known as dependency injection and is often used in combination with inversion of control which provides additional means to implement the actual injection at runtime (i.e. through an IoC container and/or via a service locator).

Strategy

You may have also noticed that the MarketFactory class that is passed to the MarketStory via its constructor is an abstract base class. This construct (as well as using a non-abstract class that can be inherited or an interface for that matter) allows for passing in different concrete implementations and is also referred to as the strategy pattern which is often used throughout this demo.

As mentioned earlier one concrete implementation of the factory can be found in the Marketplace library: the RandomMarketFactory class. This class implements the market creation process by fetching a random market object and some random person objects from a data repository. While doing so it also adheres to a list of MarketFactorySettings that indicate the exact amount of people to fetch.

The FixedMarketFactory class was introduced by the GUI project and provides a slightly different implementation by fetching the first market and the first person objects from the data repository.

Repository

The repository pattern recommends using a repository class which mediates between a data store and the middle layer. The repository provides an interface which allows the data store to be queried against and it will return middle layer entities rather than raw data sets. Whether you are using a DAO implementation with ADO.NET, a micro framework like Massive or any other ORM for that matter, it is always a good practice to encapsulate this implementation.

I find this approach to be very elegant and in combination with inversion of control it completely removes any of the dependencies between middle and data layer. If you open up the demo in Visual Studio for example, you will notice that the Marketplace project has no references to the Data project.

Another big advantage is that it really improves testability of the middle layer, especially for unit testing. The FakeDataRepository demonstrates this by implementing the IMarketDataRepository and by returning fake data. Although I did not create any unit tests for this demo, the RandomMarketFactory had been working with fake data all along (notice the poor man’s IoC in its parameterless constructor, newing up a FakeDataRepository by default if none was provided).

In fact the demo app does not even implement a data layer at all. The GUI project has a reference to the Data project and it introduces a MarketDataSql class representing a repository that allows querying against a SQL database (notice how it wraps an instance of SqlDbProvider which lives in the data layer).

The SqlDbProvider has not been implemented, so if you would go back to the Program’s Main method and have a story created using an instance of MarketDataSql, you should end up with a not implemented exception being thrown.

Singleton

If you look at the (non-)implementation of the SqlDbProvider class you should recognize the singleton pattern being used. I realize that the singleton is a much criticized pattern (and often righteously so) as it can introduce dependencies that are difficult to overcome (spaghetti code) a.k.a. an anti-pattern.

It does have its advantages however, and I would like to stress out that a singleton is an excellent strategy for simple caching purposes and it can also reduce the resource costs associated with instantiating very large objects, like for example the SqlDbProvider. Data access objects and classes implementing the provider model tend to grow large and if the application were to be extremely database-driven instances would have to be newed up very often.

Also worth mentioning is that in this case the SqlDbProvider is wrapped by the MarketDataSql repository class which should reduce the amount of dependencies and even if this repository were to be newed up in several locations one could surely just introduce a factory class that ensures the dependency is isolated.

Decorator

The entire purpose of this demo is to demonstrate how a class library or a framework can be extended by introducing new classes. The MarketStoryWithGreetings class demonstrates this by inheriting most of its behavior from MarketStory and by adding new functionality in the template method RunStoryLine. The new functionality in this particular class will have people greeting each other randomly as shown in the output window below.

Although in most cases inheritance fits this job perfectly there are times where you want to mix up or combine extended functionality and you will see the number of specialized classes grow rapidly.

The decorator pattern takes care of this problem and encourages a different strategy for adding functionality to an existing class. The demo app demonstrates this by introducing the abstract class MarketStoryDecorator which basically wraps a MarketStory object as the object being decorated while also providing the exact same interface by implementing the MarketStory and by delegating its behavior back to the decorated object. The decorator class serves as a base class for concrete decorations, of which implementations you can find in MarketStoryWithReport and MarketStoryWithExtendedReport.

In the snapshots below you can see how these two classes are instantiated as well as the output that is generated in the console window when the application launches (notice the reports at the end of story).

One drawback of this implementation is that the decorators require the MarketStory being decorated to expose the Market object it encapsulates as it is needed for the decorators to generate the reports. Then again this is just a small sacrifice if you consider the decorators allow us to extend functionality at runtime.

As for the fun part, now we can start combining these different implementations, for example if we combine the MarketStoryWithGreeting with a MarketStoryWithExtendedReport the story will contain both greetings and an extended report, as shown in the snapshot below.

A few more additions

Although I pretty much covered all of the design patterns that are used throughout this demo there still are a few abstractions and extensions left unexplained.

For instance abstracting out the state broadcasting mechanism has introduced some complexity to the design and although purists may argue I do believe the implementation follows the mediator pattern.  Either way the most important takeaway is that the combination of IStateEventSubscriber, IStateNotifier and the StateEventListener implementation allow for future classes used within future stories to broadcast their state changes to the event listeners that were registered by the story.

An example of a new state event listener added in the GUI project is the FileEventListener which will output the story to a text file if provided with a file path. An example is shown in the snapshot below.

As a final example I would like to mention the PoliceOfficer class which was added in the GUI project. It implements the behavior that is triggered by a story line and also overrides the behavior when a person is greeted. Since the FakeDataRepository does not provide fake data for police officers and nor does the AppConfigMarketFactorySettings provide a setting for the number of policemen to generate, two additional classes have been introduced to provide this functionality: FakeDataRepositoryPatrols and MarketFactorySettingsPatrols. Let’s update the program and launch it one more time.

Conclusion

A well-designed OO application allows for developers maintaining the application to add or extend functionality without having to change its source code or recompile. And although you cannot guard against all future changes, a SOLID design and the proper use of design patterns will result in a more flexible and maintainable application or framework.

I hope both this demo and blog post contribute in helping others better understand some of the most commonly used design patterns, the problems they solve or why these problems need to be addressed in the first place.

Feel free to use the demo application for you own needs, or you can just fork it on github if you would like to extend it or contribute. Cheers!

This post deals about a WordPress plugin that improves the categories widget that comes with WordPress.

As it goes with indecisive clients and lazy developers, I wrote a WordPress widget that (partially) encapsulates WP’s wp_list_categories function. I only included the parameters that were needed for the project, but you could easily add more to the mix. I advice you to go through the description of the function as to avoid unexpected behaviour of the widget.

If changes are needed to the categories, you can make them easily through the widget interface in the back end. As the IDs of categories tend to be different over time on staging and production sites, this widget proved to be extremely useful, especially if a third party is involved to take care of writing blogposts, not to mention the role of an indecisive client. The standard categories widget was a bit too basic.

Let’s dive straight into it!

namespace TheseDays;

// register the widget
add_action( 'widgets_init', function(){
     return register_widget( 'TheseDays\listCategories_Widget' );
});

class listCategories_Widget extends \WP_Widget
{

To avoid collision with other widgets with the same name I used the TheseDays namespace. Go through the Widget API fast, so you know what I’m talking about. Please note the backslash in front of the class we’re extending, you’ll get an error if you forget this because PHP (5.3 and up) will try to extend the new class from the WP_Widget class within the same namespace, more info about namespaces in the docs.

‘Child of’ accepts only one parameter, inserting multiple will result in displaying every category (except those in the ‘exclude’ box). The ‘view all’ link only shows up when this parameter is present.

Slugs and Regular Expression

			$category = get_category_by_slug($single);
			$categoryId = $category->term_id;
			// (integer if 0, string if ID)

The widget expects input for ‘include’ and ‘exclude’ parameters to be a seperated list of categoryslugs. It gets rid of nonexisting slugs and unwanted characters. These unwanted characters and spaces serve as listsepartors but will be replaced by comma’s. This is exactly the reason to use slugs instead of the names, names can contain ampersands, spaces and what not.

// source array
		preg_match_all('/([\w\-]+)/i', $string, $categories);
		$categories = $categories[0];

If you wish to change this to allow more or other characters, please change the regular expression. If you wish to add unicode to the range of allowed characters, please mind PCRE modifiers, you should be good by adding ‘u’ behind the ‘i’.

Conclusion

Aside from those the plugin is pretty basic and straight forward. Tell us what you think about it in the comments!

Here’s the full code:

<?php
/**
 * Plugin Name: listCategories Widget
 * Plugin URI: http://labs.thesedays.com/blog/2012/11/08/list-categories-widget/
 * Description: A widget that encapsulates wp_list_categories.
 * Version: 1.2
 * Author: Pieter Pelgrims <hello@pieterpelgrims.com>
 * Author URI: http://www.pieterpelgrims.com/
 *
 */
namespace TheseDays;

// register the widget
add_action( 'widgets_init', function(){
     return register_widget( 'TheseDays\listCategories_Widget' );
});

class listCategories_Widget extends \WP_Widget
{
	 // Register widget
	 public function __construct()
	 {
		parent::__construct(
	 		'listcategories_widget', // Base ID
			'List Categories', // Name
			array( 'description' => __( 'A widget that allows you to easily list categories. This widget encapsulates wp_list_categories.', 'listcategories_widget' ), ) // Args
		);
	}

	// Front end output of our widget
	public function widget( $args, $instance )
	{
		extract( $args );

		// Our variables from the widget settings.
		$title		= apply_filters('widget_title', $instance['title'] );		

		$cat		= get_category_by_slug($instance['cat']);
		$cat		= $cat->term_id;

		$view		= isset( $instance['view'] ) ? $instance['view'] : FALSE;
		$count		= isset( $instance['count']) ? $instance['count']: FALSE;
		$orderby	= $instance['orderby'];
		$sort		= $instance['sort'];

		$exclude = $this->nameToId($instance['exclude']);
		$include = $this->nameToId($instance['include']);

		$cat_args = array(
			'title_li'     => __( '' ),
  			'orderby'      => $orderby,
  			'order'        => $sort,
  			'show_count'   => $count,
 			'child_of'     => $cat,
 			'exclude'	   => $exclude,
 			'include'	   => $include
		);

		// Before widget (defined by themes).
		echo $before_widget;

		// Display the widget title if one was input (before and after defined by themes).
		if ( $title )
			echo $before_title . $title . $after_title;

		echo '<ul class="listcategories_widget">';

		wp_list_categories( $cat_args );

		if( $instance['view'] && !empty($instance['cat']))
		{
			echo "<li class=\"view_more\"><a href=\"?category_name=".$instance['cat']."\">View all</a></li>";
		}

		echo "</ul>";

		// After widget (defined by themes).
		echo $after_widget;
	}

	// Update the widget settings.
	public function update( $new_instance, $old_instance )
	{
		$instance			= $old_instance;
		$instance['title']	= strip_tags( $new_instance['title'] );
		$instance['cat']	= strip_tags( $new_instance['cat'] );
		$instance['view']	= $new_instance['view'];
		$instance['count']	= $new_instance['count'];
		$instance['orderby']= $new_instance['orderby'];
		$instance['sort']	= $new_instance['sort'];

		$this->nameToId($new_instance['exclude']);
		$instance['exclude'] = $new_instance['exclude'];

		$this->nameToId($new_instance['include']);
		$instance['include'] = $new_instance['include'];

		return $instance;
	}

	// Backend of the widget
	public function form( $instance )
	{
		// Set up some default widget settings.
		$defaults = array( 'title' => __('Categories', 'listcategories_widget'), 'view' => true, 'count' => true, 'orderby' => 'count', 'sort' => 'ASC'  );
		$instance = wp_parse_args( (array) $instance, $defaults ); ?>

		<p>
			<label for="<?php echo $this->get_field_id( 'title' ); ?>"><?php _e('Title:', 'hybrid'); ?></label>
			<input id="<?php echo $this->get_field_id( 'title' ); ?>" name="<?php echo $this->get_field_name( 'title' ); ?>" value="<?php echo $instance['title']; ?>" class="widefat"/>
		</p>

		<p>
			<label for="<?php echo $this->get_field_id( 'cat' ); ?>"><?php _e('Child of: (leave empty for all)', 'listcategories_widget'); ?></label>
			<input id="<?php echo $this->get_field_id( 'cat' ); ?>" name="<?php echo $this->get_field_name( 'cat' ); ?>" value="<?php echo $instance['cat']; ?>" class="widefat"/>
		</p>

		<p>
			<label for="<?php echo $this->get_field_id( 'exclude' ); ?>"><?php _e('Excluding:', 'listcategories_widget'); ?></label>
			<input id="<?php echo $this->get_field_id( 'exclude' ); ?>" name="<?php echo $this->get_field_name( 'exclude' ); ?>" value="<?php echo $instance['exclude']; ?>" class="widefat"/>
		</p>

		<p>
			<label for="<?php echo $this->get_field_id( 'include' ); ?>"><?php _e('Including:', 'listcategories_widget'); ?></label>
			<input id="<?php echo $this->get_field_id( 'include' ); ?>" name="<?php echo $this->get_field_name( 'include' ); ?>" value="<?php echo $instance['include']; ?>" class="widefat"/>
		</p>

		<p>
			<label for="<?php echo $this->get_field_id( 'orderby' ); ?>"><?php _e('Order By:', 'listcategories_widget'); ?></label>
			<select id="<?php echo $this->get_field_id( 'orderby' ); ?>" name="<?php echo $this->get_field_name( 'orderby' ); ?>" class="widefat" style="width:100%;">
				<option <?php if ( 'ID' == $instance['orderby'] ) echo 'selected="selected"'; ?> value="ID"><?php _e('ID','listcategories_widget'); ?></option>
				<option <?php if ( 'name' == $instance['orderby'] ) echo 'selected="selected"'; ?> value="name"><?php _e('Name','listcategories_widget'); ?></option>
				<option <?php if ( 'slug' == $instance['orderby'] ) echo 'selected="selected"'; ?> value="slug"><?php _e('Slug','listcategories_widget'); ?></option>
				<option <?php if ( 'count' == $instance['orderby'] ) echo 'selected="selected"'; ?> value="count"><?php _e('Count','listcategories_widget'); ?></option>
				<option <?php if ( 'term_group' == $instance['orderby'] ) echo 'selected="selected"'; ?> value="term_group"><?php _e('Term Group','listcategories_widget'); ?></option>
			</select>
		</p>
		<p>
			<label for="<?php echo $this->get_field_id( 'sort' ); ?>"><?php _e('Sort:', 'listcategories_widget'); ?></label>
			<select id="<?php echo $this->get_field_id( 'sort' ); ?>" name="<?php echo $this->get_field_name( 'sort' ); ?>" class="widefat" style="width:100%;">
				<option <?php if ( 'ASC'  == $instance['sort'] ) echo 'selected="selected"'; ?> value="ASC" ><?php  _e('Ascending','listcategories_widget'); ?></option>
				<option <?php if ( 'DESC' == $instance['sort'] ) echo 'selected="selected"'; ?> value="DESC"><?php _e('Descending','listcategories_widget'); ?></option>
			</select>
		</p>

		<p>
			<input class="checkbox" type="checkbox" <?php checked( $instance['view'], 'on' ); ?> id="<?php echo $this->get_field_id( 'view' ); ?>" name="<?php echo $this->get_field_name( 'view' ); ?>" />
			<label for="<?php echo $this->get_field_id( 'view' ); ?>"><?php _e('Show "View all" link', 'listcategories_widget'); ?></label>
		</p>

		<p>
			<input class="checkbox" type="checkbox" <?php checked( $instance['count'], 'on' ); ?> id="<?php echo $this->get_field_id( 'count' ); ?>" name="<?php echo $this->get_field_name( 'count' ); ?>" />
			<label for="<?php echo $this->get_field_id( 'count' ); ?>"><?php _e('Show post counts', 'listcategories_widget'); ?></label>
		</p>

	<?php
	}

	// Helper function
	// @var		string	comma seperated category names, removes non-existing
	// @return	string	comma seperated category ID's
	public function nameToId(&$string)
	{
		if(empty($string)) return NULL;

		// source array
		preg_match_all('/([\w\-]+)/i', $string, $categories);
		$categories = $categories[0];

		// target array
		$listOfIds	= array();

		foreach($categories as $k => $single)
		{
			// 0, if failure and ID of category on success.
			$category = get_category_by_slug($single);
			$categoryId = $category->term_id;
			// (integer if 0, string if ID)
		    if($categoryId !== 0)
		    {
		    	// Category actually exists, add it to target array
		    	$listOfIds[] = $categoryId;
		    }
		    else
		    {
		    	// Category doesn't exist, remove from source
			    unset($categories[$k]);
		    }
		}
		$string = implode(', ', $categories);
		return implode(',', $listOfIds);
	}

}

?>

The video was streamed using Wowza Media Server (though Flash Media Server works in much the same way) and the servers itself were behind a load balancer.

First, we tried using the FLVPlayback component, but the component was opening multiple connections, where only one connection was really required and it didn’t handle disconnects well. That’s why we opted for the good old NetConnection/NetStream approach.

However, because the content was behind  a load balancer, we got back a ‘NetConnection.Connect.Rejected’ status code. The reason why is because the load balancer will interpret the request and then sends back a redirection link to the server it wants you to connect to.

We used the following code to fetch said redirection link (remember, this example uses AS2 syntax):

// define the variables to hold the NetConnection and NetStream classes.
var WowzaConnection:NetConnection = new NetConnection();
var WowzaStream:NetStream;

// initiate the connection and add an event handler
WowzaConnection.onStatus = statusHandler;
WowzaConnection.connect("rtmp://your-streamer-url/");

// this is just a quick helper function to easily close the connection
function closeConnection(){
 WowzaConnection.close();
 WowzaStream.close();
}

function cuePointHandler(infoObject:Object){
 // insert cue point processing here
 // or leave blank if you don't need to process cue points
 // be sure to add this handler however, since Flash will throw an error if it isn't available
}

function metaDataHandler(infoObject:Object){
 // insert metadata processing here
 // or leave blank if you don't need to process metadata
 // be sure to add this handler however, since Flash will throw an error if it isn't available
}

// definition of the status event handler
function statusHandler(infoObj:Object){
 trace("onStatus: "+infoObj.code);
 switch(infoObj.code){
  // The connection was established. Initiate the stream and add event handlers.
  case "NetConnection.Connect.Success":
  WowzaStream = new NetStream(WowzaConnection);
  WowzaStream.onCuePoint = cuePointHandler;
  WowzaStream.onMetaData = metaDataHandler;
  WowzaStream.onStatus = statusHandler;
  WowzaStream.play("streamname");

  // add the stream to a Video object placed on the stage, with it's instance name set to 'video'
  video.attachVideo(WowzaStream);
  break;
 case "NetConnection.Connect.Rejected":
  // here's the reject... The load balancer rejects the connection, but passes a redirect URL
  // back through the infoObj.ex.redirect parameter.
  if (infoObj.ex.code == 302) {
   // connect to the new streamer URL after a timeout of 100ms
   // the timeout isn't necessary, but is implemented to prevent
   // unwanted behaviour
   setTimeout(function(){
    WowzaConnection.connect(infoObj.ex.redirect);
   }, 100);

 }
 break;

 }
}

And that’s about it really. The NetConnection will try to connect to the streamer URL, but will disconnect once the server throws the ‘NetConnection.Connect.Rejected’ status. After that, it will reconnect to the redirect URL and the connection should throw a ‘NetConnection.Connect.Success’ status. ]]> http://labs.thesedays.com/blog/2012/07/09/streaming-wowza-content-and-load-balancers/feed/ 0 http://labs.thesedays.com/blog/2012/07/09/streaming-wowza-content-and-load-balancers/?utm_source=rss&utm_medium=rss&utm_campaign=streaming-wowza-content-and-load-balancers http://feedproxy.google.com/~r/TheseDaysLabs/~3/J_PlheW_IkU/ http://labs.thesedays.com/blog/2012/03/12/its-agency-life-jim-but-not-as-you-know-it/#comments Mon, 12 Mar 2012 14:43:04 +0000 Sam Serrien http://labs.thesedays.com/?p=1816 Check our new microsite http://playground.thesedays.com to experience agency life at These Days. Of course we don’t do this without a reason … We need loads of new geeks so if you want to come work in this environment, check out the job pages! (You can find the jobs inbetween the life tiles on playground or directly via http://labs.thesedays.com/jobs/)

The job descriptions are boring as hell though ;-)

It’s us, the developers, who have to figure out where and on which layout/browser/os these bugs manifest themselves. This can be a very frustrating & time-consuming task, so that’s why we made ourselves a little helper.

Meet: SUD. It’s a smart little bookmark widget. Some javascript code that creates a small overlayer head-up display (HUD) with a bunch of info.

It gives you:
- A number representing the current “layout” in your responsive site (we like to number our different layouts)
- The current active media query
- All necessary browser info
- All OS info needed

Here is a little screenshot:

SUD is still in BETA, it’s a work in progress. You can find it on github if you want to see how it works.
Or simply start using it now by dragging this link to your bookmarks bar or by creating a new bookmark with this in the link field:

javascript:(function(){s=document.createElement('script');s.type='text/javascript';s.src='https://thesedays.blob.core.windows.net/labs-thesedays-com/sud/td.plugin.sud.min.js?v='+parseInt(Math.random()*99999999);document.body.appendChild(s);})();

If you want the widget to run at page load, just include this script tag:

<script type="text/javascript" src="https://thesedays.blob.core.windows.net/labs-thesedays-com/sud/td.plugin.sud.min.js"></script>

Feel free to check it out and give it a go. And make sure to let us know what you think of it!

Whenever you need to create an interactive widget on a website you often end up writing a lot of code in having the widget updated through asynchronous calls between client and server. Moreover in most cases the widget will pull for updates while it would be much more efficient in having the server push updates to its clients. This is where SignalR comes in: a signaling library for ASP.NET which does all the heavy lifting for you, making it dead easy to push data from server to client(s).

The best way to get started with SignalR is by looking at Hubs which are a higher level implementation of a persisted connection. Check out the quick start example and see how easy it is. Note that in order to support certain browsers you will need to include json2.js in your application.

Why create a progress bar using SignalR?

In our production department we have several (web based) collaboration tools amongst which a deployment tool for .NET based websites. The tool allows front-end developers to work against a shared development environment (not having to run websites on their local machines) and deploy websites to a staging environment which is accessible to our clients for previewing and acceptance testing.

Since deploying larger websites can take up to several minutes we needed to provide the user with feedback, preferably by means of a progress bar. We also needed to make sure that during website deployment the deployment could not be reinitiated and finally we thought it would be really cool if we could prompt the progress bar to other (concurrent) users as well.

And although this could also be accomplished with Ajax/JSON, it is just so much easier using SignalR!

Let’s see this in action: the screenshots below represent 3 different browser windows showing 2 simultaneous deployments. When a user visits the deployment page of a website a progress bar is prompted if the website is currently being deployed. The overview page which lists all the websites is updated as well (a rotating progress loader is shown instead of the deploy button)

Deploying a first website

Deploying a second website

Overview which lists all websites and their deployment status

A look at the source code

The deployment tool is an ASP.NET MVC 3 web application so installing SignalR is a breeze with NuGet and the first thing I did after installing the package was adding the progress bar to the view which initiates the deployment.

Client-side code in the Deployment view

In the head section I added references to the scripts required for SignalR and the JQuery UI progress bar as well as some JS code which initializes the Hub and handles the progress updates. Instead of having the form post back to the server, the submit button triggers a client side click event which will call a method on the hub (in this case run). Note that Jquery itself also needs referenced (in a shared layout).

That’s pretty much it when it comes to client side code and as you can see below the actual implementation of the hub is written in plain old C#

DeployManager: server-side implementation of the hub

All it takes is creating a class which derives from SignalR.Hubs.Hub and by doing so the run method that is executed in the client-side script will trigger the run method on this class, which is all handled by SignalR.

The actual deployment logic is implemented in the WebAppManager class, so the run method just creates a new worker thread and passes in the deployment info. The worker thread instantiates a WebAppManager and subscribes to the progress event which will bubble progress events back to the DeployManager. Finally, the DeployManager will update the progress to all its clients (also handled by SignalR) which causes the updateProgress method on all clients to fire. Isn’t that just awesome?

Finally, the view which lists all websites can be easily updated by adding some familiar client-side script.

Client-side code in the App Management view

Whenever a progress update is received the script will check to see whether a website’s deploy icon (and alt/title text) needs to be switched back and forth.

And apart from the actual progress calculation, basically that is all there is to it!

Related files: download the source code – download the web application

Jupiter is just around the corner

With its first beta release on November 11^th the road to Umbraco 5 (aka Jupiter) has brought us very close to its destination. The members of the Umbraco core team have been working really hard on stabilizing the API and many of our beloved (and improved) CMS features are well taking shape.

As Umbraco 5 remains open source all current and future releases are made available through Codeplex which allows developers of the Umbraco community to explore and work with the source code, to contribute and to provide the core team with valuable feedback.

After having attended the awesome Umbraco v5 hackathon organized by BUUG and hosted at our offices in Amsterdam – and also very much inspired by Alex Norcliffe’s talk at the Microsoft offices in Brussels – we really wanted to get our hands dirty and – deep dive into hive!

Umbraco Hive

Many of the recent Umbraco 5 talks and presentations involve Hive, a completely new and extremely powerful concept in the upcoming version. Much unlike a traditional data layer in most n-tier or n-layer (web) applications Hive represents an abstraction layer for developers to plug in multiple, stackable data providers. These Hive providers can pull data (read and/or write) from nearly any data source and allow for smooth integration within the Umbraco back office as well as a transparent way of querying the data in the front-end.

The first beta release comes with three Hive providers, created by the core team:

• A persistence provider that already supports SQL server and SQL CE (which uses NHibernate as ORM)
• An Examine provider for data indexation (which uses the Lucene.NET indexer)
• An IO provider which stores data on the local file system

Basically this means Hive already supports the vast majority of (.NET) based websites.

By the way, didn’t I mention these providers are stackable? In a recent demo (video currently not available yet) Alex quickly swapped the Examine provider with the persistence provider, having Umbraco run entirely on a file index without using a database at all. Although that’s a neat trick by itself, the true power of Hive is the ability to query multiple, stacked providers: imagine having data stored in both a database and a file index while data is always retrieved from the file index in order to gain a performance boost… Hive will make it work.

Community hackathons

In many countries the ongoing v5 hackathons allow Umbraco developers to come together, share experiences, learn and contribute. These sessions are the perfect opportunity to experiment with the various new concepts in v5 such as hive, hive providers, property editors, surface controllers, tree controllers and much more.

During the BUUG hackathon we were able to play around with the WordPress Hive provider created by the Karminator. Basically the provider connects to a WordPress blog and fetches categories and posts which are then loaded into the Umbraco back office. And even though our efforts of making the provider writeable were somewhat fruitless (#h5is) it did allow us to get familiar with Hive and understand how to create and configure a custom Hive provider.

The source code of the WordPress hive provider can be found on bitbucket and has also been added to the Umbraco 5 Contrib project on Codeplex which was introduced during the recent UK hackathon.

Since we weren’t able to attend the Umbraco UK festival and we didn’t want to wait until the next hackathon to further explore v5, we started a somewhat experimental side project: whether or not the websites we create are hosted on Windows Azure we often want to store resources on Windows Azure CDN or blob storage. In Umbraco v5 style sheets, scripts, templates and media uploads are stored on the local file system. All of this is handled by the IO Hive provider, so we decided to create a Hive provider which is to save these files on blob storage, and it works!

As for the more technical part of this post, let’s have a closer look at the setup.

Configuring the Blob Storage Hive provider

When you have a closer look at the Hive configuration file you will notice that a Hive provider can be configured separately for each of the storage types known by Umbraco.

The hive configuration file, located in App_Data\Umbraco\Config

The configuration file allows you to configure the type of the Factory class that is used by Hive to instantiate the provider’s entity repository (more on this later) as well as a reference to the provider configuration section which is located in the web.config. As shown below this configuration section allows users to further configure the Hive provider.

The umbraco configuration section in web.config

As for the blob storage provider we allow users to configure the name of the connection string of the blob storage account (which is to be added to the connection strings section) as well as the name of the blob container.

Creating a custom configuration section is fully supported by the Umbraco v5 Framework and is just a matter of creating/inheriting some classes that will allow the settings to be injected into the Entity repository (handled by IOC, very sweet). Make sure to have a look at the source code to find out exactly how easy it is ;-)

The provider dependency helper is a property of the abstract entity repository

Creating the Blob Storage Hive provider

Although we haven’t gotten around testing the provider for all storage types just yet, obviously the first thing we had in mind was having the provider handle media file uploads. The one thing which distinguishes media from other storage types is is that it uses both a persistence provider and a storage provider. This approach provides a (much needed) separation of the concept of media on the one hand and the actual physical storage on the other hand (I will come back to this in a moment).

As we won’t be replacing the persistence provider we were able to reuse plenty of the code written for the IO provider. So instead of walking through all the code, let’s just have a look at the key differences (and imperfections).

When you create a custom Hive provider you start out with creating an Entity model and a schema, allowing you to convert an arbitrary data model into a model which can be interpreted by Hive. Hive provides base entity classes for both model and schema (currently TypedEntity and EntitySchema) and base repository classes (currently AbstractEntityRepository and AbstractSchemaRepository) which allow Hive to query against model, schema and relations.

The main problem we faced when creating a model and schema for blob storage is that we noticed the core property editor used for uploading files in the back office creates a File model (IO provider). Since we did not want to create a custom upload property editor just yet, we decided to have our Blob model derive from the File model instead.

The Blob typed entity which derives from Umbraco.Persistence.Model.IO.File

Definitely something we will need to reconsider in the future, but for the sake of getting the project of the ground quickly it seems like a fair solution. This is also the reason why we didn’t put too much effort in tailoring the Blob schema just yet (a simple schema with a node name attribute seems to work just fine).

Next we copy/pasted the entity repository used by the IO provider and implemented most of the key logic in having data stored on blob storage. This actually all went pretty smooth and the one thing worth mentioning here is probably the use of Hive ID’s. The IO provider assembles Hive ID’s by normalizing the file path and although I’m sure it makes perfect sense we didn’t get it straight away and decided to implement our own strategy which basically comes down to: blob – container – blob name (which includes the GUID of the persisted media).

Although we haven’t yet fully implemented all of the entity/relation operations (and revision support for that matter) we did implement some of the relation operations which basically allow for the creation of thumbnails (AddRelation and PerformGetChildRelations). Having these implemented was amazingly straightforward by the way, so a big thumbs up to the core team! And again, you should really check out the source code to find out just how easy it was ;-)

The AddRelation method of the Entity Repository

That’s basically it, and now we seriously wanted to test-drive this baby! Unfortunately the upload property editor did require a small fix in order to make it work with our blob storage provider: the code used to create a thumbnail creates a bitmap by passing in a file path. To fix this we just had to replace 1 line of code (maybe 20 characters?) which I think still is impressive considering we are reusing the existing property editor ;-)

A small fix in the core Upload property editor

And it just works!

Media section in a local Umbraco v5 beta installation

Cloudberry explorer showing the media files on blob storage

We were actually somewhat surprised to see it work immediately as we first figured we would still have to make some changes in having the editor display the thumbnails (they’re on blob storage, so what about the URL?) and this is when we found out Umbraco 5 uses a custom mechanism for rendering media, i.e. the following URL will display an image uploaded as media:

http://umb5beta.local/Umbraco/Media/Proxy/media%24empty_root%24%24_p__nhibernate%24_

v__guid%24_28a171dda97048f98e6b9fa501792a5b?propertyAlias=uploadedFile

Remember the separation of the concept of media and the actual physical storage I mentioned earlier? Right!

What’s next?

Although we realize this is just a very basic implementation we would certainly love to see it being further developed into a solid Jupiter hive provider, and of course we love to hear your feedback and suggestions.

The source code is available on the Umbraco 5 contrib project (forked) or  you can just download it here or download a full web application which has the provider already configured (it uses SQL CE so no need to setup a database).

At These Days we are already looking forward to the next release of Jupiter!

That’s why it’s time for responsive awareness. The presentation included in this blogpost exists out of three parts and is intended for everybody with an interest in responsive web design and development, designers and front-end developers. Are you ready to make the switch? Do you want to deliver optimal user experience at all times? Get responsive already.

Demo

check it out

Look ma, no javascript. Without scripting however IE6, IE7 & IE8 won’t display properly. If you would like to see this work in every browser known to mankind simply include respond.js. While viewing the demo, screen resolutions are displayed in the upper left corner. Depending on your screen size you can see up to seven different layouts.  The css is dynamic thanks to less.

Presentation

This presentation aims to shed light on do’s and don’ts for both designers and front-end developers. You can expect some tips on how to approach a responsive project, how to optimize the website for speed and plenty more.

Geolocation is used to center the map and show the user’s exact position in Antwerp. As you ride around the city your new location is automatically represented on the map.

The serverside part of the application is built with NodeJS to be blazing fast. It constantly scrapes data from the official velo-antwerpen.be website and stores it as a JSON file. NodeJS is fast because it is an event driven server. After the server sends out a scraping request it will rest, and CPU usage will go down to zero, until it receives a response. This allows it to manage many simultaneous tasks.

On the client side, scripts and stylesheets are included as inline code to reduce the number of HTTP requests made and improve the performance of the app.

All code for the project is open source and available on GitHub, so if you’d like to improve something about the website, feel free to make your own changes and submit a pull request.

There are a number of reasons we built this as an HTML5 web app rather than a native app.

The most important reason is cross-device support. The Google Maps SDK we use already supports iPhone, Android, BlackBerry 6 and Dolfin 2 (Samsung Beda). As other manufacturers improve their mobile web browsers, Dude Where’s My Velo will automatically support those devices. We are expecting good support for Windows Mobile and Nokia devices later this year.

The second reason for web over native is bug fixes and feature updates. Web apps can be updated as quickly and easily as normal websites. Changes don’t have to be approved or reviewed by third parties.

So check it out now. Visit dudewheresmyvelo.be on your phone or computer. We would also like to give a shout out to DotCloud who are hosting the app for free. Happy cycling!