Extracting the Func

Recently, I’ve found myself using Generic Delegates quite a lot, and in particular the Func<> delegate. Delegates can be a great way of reducing duplication and increasing code re-use.

The following is a rather contrived example, and mostly useless, but it helps to illustrate the process of what I like to call “Extracting the Func”

Say you have a method that writes to the console, the result of adding two numbers together:


public void WriteResultOfCalculation(int x, int y)
{
     Console.Write((x + y).ToString());
}

But then, u decide you want similar functionality, but instead of adding x and y you want to multiply x and y (besides obvious ways of doing this) you could extract the calculation into a Func delegate like this:


public void WriteResultOf(Func<int, int, string> calculation)
{
     Console.Write(calculation);
}

WriteResultOf((x,y) => (1 * 2));

Here we have pushed the responsibility of performing the calculation to the consumer. This code is quite useless, but I’ve intentionally used this example so not to distract from the point.

The next example of this pattern, hopefully, shows how this can be useful. A few weeks ago, I was working with a repeater control in an asp.net site. The repeater contained a usercontrol with multiple grids and I needed easy access to manipulate every instance of this usercontrol in the repeater. So I whipped up a quick extension method for Repeater controls modeled on the IList ForEach extension:


        public static void ForEach<TControl>(this Repeater repeater, Action<TControl> action) where TControl : Control
        {
            foreach (RepeaterItem item in repeater.Items)
            {
                foreach (Control control in item.Controls)
                {
                    Repeater nestedRepeater = control as Repeater;
                    if(nestedRepeater != null)
                    {
                        nestedRepeater.ForEach(action);
                    }

                    TControl t = control as TControl;
                    if(t != null)
                    {
                        action(t);
                    }
                }
            }
        }

This method has a type parameter of TControl, which is constrained to types derived from “Control”. This is the type of the control that you are wishing to gain access to, within the repeater. It iterates the RepeaterItems of the repeater, and nested in this, it iterates the controls of each RepeaterItem. Within the nested loop, it first performs a safe cast to typeof(Repeater), and performs a recursive call if the cast is successful. Finally, a safe cast is performed to TControl, and if successful it calls the Action delegate, passing in the instance of TControl as the argument.

In a nutshell, it performs recursion to find all instances of the type TContol within the repeaters nested controls, then performs the action, specified by the consumer, on the control.

The signature of Action is a method that accepts a paramter of type TControl and returns void:


void Action(TControl control);

As the ForEach is modelled on ILists ForEach, its usage should be fairly intuitive. For example, lets say the control we are after has a public method “LoadReport”, and we’d like to call this method for each instance inside the repeater, we can call it like this:

    repeater.ForEach(control => control.LoadReport());

Piece of cake. Now as I wasn’t happy leaving this nested loop, essentially hiding the intent of code, I’ve refactored it a little, breaking down into 4 smaller methods:

        public static void ForEach<T>(this Repeater repeater, Action<T> action) where T : class
        {
            repeater.ForEachNestedRepeater(action);
            foreach (T t in repeater.GetItemsOfType<T>())
            {
                action(t);
            }
        }

        private static void ForEachNestedRepeater<T>(this Repeater repeater, Action<T> action) where T : class 
        {
            repeater.GetItemsOfType<Repeater>()
                    .ForEach(r => r.ForEach(action));
        }

        private static IEnumerable<T> GetItemsOfType<T>(this Repeater repeater)
        {
            return repeater.Items.Cast<RepeaterItem>()
                                 .Select(item => item.Controls)
                                 .OfType<T>();
        }

        private static void ForEach(this IEnumerable<Repeater> repeaters, Action<Repeater> action)
        {
            foreach (var repeater in repeaters)
            {
                action(repeater);
            }
        }

Happy coding!

Windows Azure Discovery Day

Just got back from Windows Azure Discovery Day with Graham Elliot. Overall a good day, covering Cloud Computing Scenarios for ISVs, Understanding the Windows Azure Platform Pricing Model, Building Applications for Windows Azure & SQL Azure, then finishing off with a few demo’s.

Useful Azure links:

Fabrikam Shipping Demo

Windows Azure SDK

Windows Azure Developer Training Kit

Cloud Cover | Channel 9

Microsoft Platform Ready

Get amongst it!

Kentico vs ValidateRequest

It seems Kentico are insisting on not encoding html sent to the server from the fckEditor. Instead, Kentico advises to turn ValidateRequest off.

That’s pretty fckEd. In this post, Kentico assure us they take security seriously;

we do a lot of investigating on this issue and fix every potentially dangerous part of the system during development stage as well as later during testing stage”

It would seem to me that encoding html from the fckEditor, in order to allow ValidateRequest not to break, would be high on their list. Apparently not.

The issue I have is, not all of the website in question is the work of kentico. In fact, the bulk of the solution is custom built, while using Kentico to leverage it’s content management. Obviously then, it would be unwise to turn off ValidateRequest for the whole site.

So enough ranting about Kentico, here’s the solution. Short of hacking the entire Kentico site to htmlencode all instances of the fckEditor, we can localise turning off ValidateRequest just to Kentico pages via directory-level web.configs and keep ValidateRequest = true at the root web.config.

Add this section to Directory level web.configs for all things kentico (ie. CMSAdminControls, CMSDesk, CMSFormControls, CMSMasterPages, CMSModules, CMSPages, CMSSiteManager)

<system.web>
 <pages ValidateRequest="false" />
</system.web>

Kentico have advised they will look at fixing this issue in later releases. However, I wouldn’t hold your breath, they’ve been saying this since 2006.

So, in short, Kentico are fckEd.

Windows Phone 7 Dev Xmass drinks in Sydney

Courtesy of Nick Harrris .NET:

 

Event:
WP7Dev XMass Drinks meet and greet

Please indicate your attendance here – http://events.linkedin.com/Windows-Phone-7-Developer-XMass-Drinks/pub/496913

Purpose:
Let’s get together for some XMass Drinks and/or dinner to trade some WP7 Dev stories and demos. Event will be informal, i.e around bar tables, so bring along your device or laptop if you wish to show people what you have been up to.

Date, Time, Location:

6-8pm
Tues 14th Dec 2010
City Hotel,
Corner of King and Kent St, Sydney CBD.

Courtesy of Nick Harris .NET

Script Helper

Good ol’ Glavy boy has posted a ScriptHelper for MVC and WebForms here.

“For example, in the page you can do

<%= ScriptHelper.RequiresScript(ScriptName.jqueryValidateUnobtrusive) %>Or

<%= ScriptHelper.RequiresScript(“jQuery-validate-unobtrusive”) %>

And you would get

<script type='text/javascript' src='/Scripts/jquery-1.4.1.js'></script>
<script type='text/javascript' src='/Scripts/jquery.validate.js'></script>
<script type='text/javascript' src='/Scripts/jquery.validate.unobtrusive.js'>

The library is currently hosted on bitbucket here http://bitbucket.org/glav/mvc-script-dependency-extension. Thanks Glavvy boy.