Omniscient's Foundation - Blog

Hi everyone!

This is my first blog. I hope the following information will help someone like me. I searched the web and navigate through the people's blogs to find my answers in this new world of caching with AppFabric Velocity!

My first post will concern the AppFabric API.
Why Microsoft don't think to have one centralized API to manage the AppFabric velocity cache? Why should we use the PowerShell command to create named cache ?
Why can we not create region with the Poweshell command ?
What is the benefit to split the cache management between Powershell commands (that we certainly needs to wrap up) and an API that gives us only a part of the potential of the AppFabric cache management ?

How deep the rabbit hole goes ?

What distinguish the line between PowerShell command and the AppFabric API ?? Is it possible to get a complete API to manage the AppFabric cache server ? (configuration, management of named caches and regions)

Enough complain, I will come back later with my own solution to solve issues related to server cache physical structure and how I minimized the use of the Powershell command that is sooooo time expensive and time consuming...

By the way, I'm using this amazing tool to format my c# code in this blog so that it's all blue and all : http://manoli.net/csharpformat/

Thank you for that great tool!

I'm currently working on a navigation service in Silverlight in order to hook perfectly Prism with the browser's navigation utilities (back, forward and URL entry). More on that later.

In doing so, I made a view whose role is to display a series of buttons hooked to commands to form a navigation bar. Each module registered with the service would get a button to navigate to it. My service holds a collection of registered modules, but it lacked a real Command object. Instead of exposing that collection, my ViewModel then exposes an enumerable list of anonymous types enriched with a command:

        public IEnumerable CommandDefinitions
        {
            get 
            {
                foreach (var entry in this.navigationService.ModuleEntries)
                {
                    yield return new
                    {
                        Command = new ModuleNavigationCommand(this.navigationService),
                        CommandText = entry.CommandText,
                        ModuleName = entry.Name
                    };
                }
            }
        }

Unfortunately, that doesn't work. The View sees that there are 2 modules and creates 2 buttons, but the buttons have no content, and when I click them, the commands don't execute! Seems like Silverlight is unable to databind on anonymous types... (does SL4 have the same problem? WPF?)

The solution is to create an holder class with the same public interface as my anonymous type, and use it instead (yes, it *has* to be public) :

        public IEnumerable CommandDefinitions
        {
            get 
            {
                foreach (var entry in this.navigationService.ModuleEntries)
                {
                    yield return new CommandDefinition
                    {
                        Command = new ModuleNavigationCommand(this.navigationService),
                        CommandText = entry.CommandText,
                        ModuleName = entry.Name
                    };
                }
            }
        }

        public struct CommandDefinition
        {
            public ICommand Command { get; set; }
            public string CommandText { get; set; }
            public string ModuleName { get; set; }
        }

Silverlight is about cutting off fat from .NET. However sometimes, I think it cuts where it shouldn't, leading to awkward voids. As mentioned in a previous post, bound commands are probably the most visible void. The way I discuss to work around the problem works perfectly however, so much that I truly think it's a shame that controls still don't support bound commands out of the box after 3 versions. By the way, please go here to vote for commands in the next version. While you're at it, wsHttpBinding would be great as well ;-)

Today, I discuss such harshly missing parts, and again, propose a nice implementation of something close enough to be used almost normally, the client-side configuration file. Most of you may have noticed that there's no ConfigurationManager class in Silverlight. Point of fact, there's no System.Configuration.dll assembly altogether. You cannot do something like this:

MyConfig config = (MyConfig)ConfigurationManager.GetSection("myConfig");

Moreover, there's no upfront "configuration file" in a Silverlight application. That being said, it's easy to add random text file to the .xap, since it's nothing else than a zip file (try renaming the extension, and open it as any other zip archive. While you're at it, try the same with .docx files...). The trick is to compile the file as "Content". Right-click the file in the solution explorer, Properties, and then Build Action = Content. The file will be put in the .xap file. Here's an example of a Silverlight configuration file:

Then you create DTO (Data Transfer Objects) to hold your section's data:

        [XmlType("mything")]
        [XmlRoot("mything")]
        public class Mything
        {
            public Mything()
            {
                this.Subthings = new List<Subthing>();
            }

            [XmlElement("subthing")]
            public List<Subthing> Subthings { get; set; }
        }

        [XmlType("subthing")]
        public class Subthing
        {
            [XmlAttribute("name")]
            public string Name { get; set; }
        }

Then, you use the new ConfigurationManager class to get your section:

All that mimics as much as possible the ConfigurationManager's behavior from .NET. It does add strongly-typed return values though. But keep in mind that this is all fake: the configuration file as shown above is nothing more than an XML file, and won't obey to the rules of a "real" configuration file. For example, I don't even have the mandatory <configSections> tag.

The new ConfigurationManager class I've added to Foundation has two methods: the one you see above, plus an extra overload that takes a second type param of type IConfigurationSectionHandler<TSection> (again, this has been added to Foundation and is not part of Silverlight's code base). That allows you to more control over what's going on, and resembles .NET configSection's "type" attribute. The overload I use in this example uses an XmlSerializer behind the scene (thus the xml attributes on the DTO classes).

Download the code here:
http://omni-foundation.googlecode.com/svn/foundation/trunk

Enjoy!

[May 31th, 2009]

For those of you who attended my speech at Code Camp Montreal last Saturday (I still can't believe how many you were!), you can download everything here:

The demo: http://www.omniscient.ca/CodeCampDemo/Default.aspx
The code: http://www.omniscient.ca/CodeCampDemo/trunk.zip
The presentation (in French): http://www.omniscient.ca/CodeCampDemo/CodeCampMontreal2009.pptx

Now, I'm leaving for a one week, well-deserved vacation!