Omniscient's Foundation - Blog

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!

In my last post, I discussed how object relations (references and collections) should be kept away from an Entity but for extraordinary cases where an entity cannot live without being attached to other entities (strong relations). I discussed that if one describes relations directly in the entity (a reference to another entity, or a collection of entities), then one adds a lot of complexity to their system, because they have to tell the backend how "deep" entities should be loaded, how deep it should look for dirty entities upon saving, deal with circular references and somehow flag the references to tell when there's just no data as opposed to when the reference is lazy loaded. Plus, one looses the ability to quickly define different object graphs with their entities.

Read more »