I started my career when I was still in university. I started a company named Sitechno that did webapplications and custom solutions. The last few years, I’ve been hired as a consultant on some big projects.
The role I was given on my last project, allowed me to do some crazy cool stuff, using nHibernate and winforms. I was able to push WCF, WF and WPF into a big client/server application, and had great success with it. We reformed a monolithic data-oriented application into a domain-oriented loosely coupled application.

It’s easy enough to find new projects, but the market for the cutting edge technologies is not very big ;-)

When I was asked to join Microsoft, my main attraction to the offer was the opportunity to work on cutting edge technology with a group of passionate people. When I talked Microsofties on the Redmond campus, it became clear that they could certainly offer just that.

I was torn between working on EF (which, I’ve been very involved with lately) and on Silverlight.
In the end, Silverlight won, because I strongly believe it to be the strongest contender in the client space, there is an interesting ‘war’ going on right now, and I have really enjoyed working with the WPF-framework in the past. I was torn by the decision because whatever choice I made, I knew that a great opportunity would be lost.

We will be heading to Vancouver, Canada in September and I will work for Microsoft Canada for a year. After that, I will be allowed to work in the U.S.A. and we will move to Redmond.

You can not believe how excited I am about this opportunity. I will be working for Shawn Burke on Silverlight Controls. I’m not sure yet who else is working on the team, but I believe/hope I’ll be working with David, Ted, Kirti and Jeff.

As for EFContrib: although I’m dedicated to it, I’m having a hard time finding the time to work on it. Also, since version 2.0 of EF will feature some nice Poco capabilities. So, I’m not sure if people are waiting for the solution. It would be nice to make it work with SL though! So, if I find the time, or get lots of mail of people wanting me to finish it properly, I’ll work on it some more.

Josh Smith just published a great article about his solution to using RoutedCommands in WPF.

The problem he solves, has been solved by others before, however, I think this is a very lightweight succinct way of doing it.
Basically, when you set a command to a button, you will have to handle that logic (canExecute and Execute) in the codebehind of the view. Since you are (hopefully) using a MVC, MVP or MVVM approach, you would rather not go through the codebehind of the view, but directly route the commands to the appropriate viewmodel/controller.

He creates a relaying object that does just that. This results in a completely empty codebehind for the view, which is exactly what I like!

Good job Josh!

Well, I wrote about one way to do deeplinking and knew that there had to be something out there that already did this.

Look no further. It’s here!

Ninject is a lightweight dependency injection framework and it has been getting quite a bit of attention lately.
What makes is superspecial, is that it runs under Silverlight 2.0 beta 2!

The Ninject website is here and Nate Kohari talks about this release here. From his post:

So, what are some of the features of Ninject 1.0?

• Constructor, property, method, and field injection
• Instantiation behaviors (singleton, one-per-thread, one-per-request)
• Fluent interface for declaring type bindings
• Contextual bindings, where the selection of which type to instantiate can be delayed until activation
• Support for instance scope and deterministic disposal
• Fully pluggable, modular design: each kernel component can be easily replaced to alter the framework’s behavior
• Lightweight interceptor support (aspect-oriented programming)
• Integrations with other popular frameworks

It’s great to see people working on MVC approaches and now even DI frameworks for SL. Keep it coming!

Nihkil wrote sometime ago about ‘actions’, which was a concept he created that attach some behavior to elements. Think of the action of pressing the ‘enter’ key in a textbutton and executing some logic (sparing the user a click on the button next to the textbutton).

He has clearly been thinking more about his framework and now posts about the MVC concept of the ViewModel, extending it with his actions here. Good write-up. Go read it.

Basically, he explains what a ViewModel is and shows how to execute ‘command’-like behavior on them. As you might know, Silverlight does not support the concepts of commands, like WPF does. His syntax is like this:

          
             1
            <
            vm:View
            xmlns="..." xmlns:x="..." 
          
             2
            xmlns:vm="clr-namespace:Silverlight.FX.ViewModel;assembly=Silverlight.FX" 
          
             3
            xmlns:app="clr-namespace:AmazonSearch.Views">
          
             4
            <
            vm:View.Model
            >
          
          
             5
            <
            app:SearchViewModel />
          
             6
            </vm:View.Model>
          
             7
          
          
             8
            <
            Grid
            >
          
          
             9
            <
            TextBox
            x:Name="searchTextBox"
/>
          
             10
            <
            Button
            Content="Search" IsEnabled="{Binding
CanSearch}">
          
             11
            <
            vm:ButtonEvents.Click
            >
          
          
             12
            <
            vm:InvokeMethod
            MethodName="Search">
          
             13
            <
            vm:ElementParameter
            ElementName="searchTextBox" ElementProperty="Text"
/>
          
             14
            </vm:InvokeMethod>
          
             15
            </vm:ButtonEvents.Click>
          
             16
            </Button>
          
             17
          
          
             18
            <
            ItemsControl
            ItemsSource="{Binding
Products}">
          
             19
            <
            ItemsControl.ItemTemplate
            >
          
          
             20
            <
            DataTemplate
            >
            <
            app:ProductView /></DataTemplate>
          
             21
            </ItemsControl.ItemTemplate>
          
             22
            </ItemsControl>
          
             23
            </Grid>
          
             24
            </vm:View>
           25
        

The thing to note is in lines 10 to 15. There he invokes a method straight on the ViewModel.

The concept is quite the same as the Caliburn project from Rob and the idea is very powerful!
It enables you to have no code-behind and go straight to the viewmodel. Very nice!

Thinking about this a bit though, does make me wonder if the added Xaml is worth the ability to go straight to the viewmodel. Wouldn't it be just as simple to define a Search method on the codebehind and invoke the correct method in the viewmodel?

My point being: is it worth to incorporate such a framework (albeit very small and succinct). What do you think?

I’ve been busy sharpening my Silverlight skills and created my very own button, complete with VSM.

The button (‘rjButton’) inherits from contentControl and in the project there is a generic.xaml which defines a default look for the button, including VSM definitions and state transitions.
When loading up my solution in Blend, I can happily get the rjButton in my page. It looks correct. However, when I ‘Edit a copy’ of the template, nothing shows up!! Funnily enough, when I use ‘Create empty’, the correct states do show up.

I was unable to google-fix the problem. I would guess that when you use ‘create empty’, Blend just looks at the attributes on your class and shows the correct states. When you ‘Edit a copy’, Blend looks for the template and can not find any. Somehow it is unaware of the link to the style in generic.xaml, and it creates an empty style.

I’ve double checked the behavior with the TabControl, which is also a control that is defined in an external control, and it works the same.
I'm not sure why controls included in the framework do work correctly. I've taken a look with reflector and I've seen nothing out of the ordinary.

You can work around this by naming the style and explicitly tell the control to use the style. But then again, it might be easier to just copy the style (use David's excellent style browser here).

If you know what is going on, leave a comment!

[update: jasonxz knows: I was informed, today, that Blend does not, yet, support the "edit a copy" functionality of a Template that is not defined in System.Windows.dll. Thnx! ]

I just spent way too much time figuring out why my VisualStateManager suddenly started giving errors. Without ‘break on all exceptions’ I got a ‘Catastrophic error’. With breaking on all exceptions I could finally see that the layout system was trying to layout the visualstatemanager.

I basically had specified my vsm directly under the controltemplate, instead of defining it inside the grid. Whoops!

I was triggered to spend some time on thinking about deeplinking, when I was listening to a podcast with Neal Ford, here.
In it, he has quite a few arguments why something like Silverlight (and Flex for that matter) will never amount to anything. I disagree with almost all of his points, but one stuck with me more: the inability to do deeplinking.

Let me start off by saying that I think the ‘normal’ html world has reached maturity and should soon begin to disappear. As almost everything in the world, technology adoption follows a wave pattern. Html has had some great advantages which made it easy to adopt. However, as computing power increases and humans become more accustomed to great applications, html as a platform does not deliver anymore. It was rejuvenated by the Ajax revolution, but in the end, you are always fighting against the restrictions that it imposes.

Those restrictions are no longer necessary. Flash did not deliver as a RIA platform, but Flex seems very capable, as does Silverlight. It will take a few years, but the demand for rich clients will drive the adoption of said technologies.

Being able to do deeplinking, is an important part of the experience and usability. The more I thought about it, the more I agreed on this. Although I think that browsers (as we know them) will cease to exist pretty soon or more likely: change to meet new needs, for the next few years we will have to deal with the restrictions they impose.
So, I started to think about how we can solve the deeplinking issue for Silverlight.

I had a flash of brilliance when I thought of the achor (#) sign in url’s. They can be navigated to, but the page is not reloaded. Exactly what was needed for deeplinking.
After doing some fast research, I discovered half the world had already thought of this trick and it is heavily used by the Flex world.
That discovery ruined my chances to score some ‘smart'-points with my girlfriend, but it won't keep me from implementing my idea ;-)

The basic idea

The idea is to get to the url at the beginning of the application and treat everything after the # sign as 'state'. This state is used by the components in our application to initialize themselves to the correct state. For instance, show the help page, or the products page.
When a component is changed and it is important enough to reflect this change in the url, we use javascript to navigate to the new url. The browser will recognize that only the anchor has changed, and will not really browse there. However, the user can now confidently copy the url.

It's pretty easy.

Two approaches

Using a navigationcontroller.
Your application could instantiate one navigationcontroller. This controller would be used inside your application to show different usercontrols etcetera. I think such an approach is well suited for a MVC-style of application architecture.
Obviously, since all your navigation is taken care of by a central component, it would be very easy to take care of 'serializing' its state to the url.

Using per component approach.
If you're just not that kind of person, you could also just make the components you care about do the (de)serializing. So, possibly react to the Loaded event of a component and reading the url to see how to initialize it.
I've taken this a step further and created a class that serializes the vertical offset of a Scrollviewer. It can be used like so:

          
             1
            <
            ScrollViewer
            x:Name="sv1" VerticalScrollBarVisibility="Auto" Margin="10">
          
             2
            <
            nav:ScrollviewerOffsetStateAttacher.Register
            >
          
          
             3
            <
            nav:ScrollviewerOffsetState
            TemplateName="HelpTemplate" PartName="pos1"
/>
          
             4
            </nav:ScrollviewerOffsetStateAttacher.Register>
          
             5
            <
            TextBlock
            TextWrapping="Wrap">
           6 Lorem ipsum dolor sit amet, conse

(pretty radical, isn't it. Here I'm serializing the amount of scrolled pixels to the url. That's something else than just which page you are viewing!)

Some more code

First off, you need to think about how the url is serialized. Some kind of template needs to be known to the system. And, different templates should be available for different parts of your application. So, during initialization of my application I do this:

            NavigationState.RegisterTemplate("MainNavigationTemplate", "mainpage");

            NavigationState.RegisterTemplate("ProductTemplate", "mainpage/product/detailpos");

            NavigationState.RegisterTemplate("HelpTemplate", "mainpage/pos1/pos2");

A better approach might be to supply regex expressions.

As you have figured out by now, I'm using a static class 'NavigationState' to manage my url fiddling. It contains a SetNamedPartState and a GetNamedPartState method. So when I navigate to the Products page, I might do this:

appController.NavigateToPage(typeof(Products));

NavigationState.SetNamedPartState("mainpage", "ProductTemplate", "products");

I'm telling it to use the producttemplate and set the mainpage part of that template to the state 'products'.
During the load though, I do the opposite:

            string state
= NavigationState.GetNamedPartState("mainpage", "MainNavigationTemplate");

            if (!String.IsNullOrEmpty(state))

{

    if (state
== "products")

        ProductsSelected();

    else if (state
== "help")

        HelpSelected();

Getting the url is easy:
string uri = HtmlPage.Document.DocumentUri.ToString();

Setting it is only slightly harder:
HtmlPage.Window.Eval(String.Format("window.navigate('{0}#{1}');",
    NavigationApplicationString, InternalStateString));

Conclusion, work ahead

It's pretty a pretty simple idea. I like the way I attached a 'state' object to a scrollviewer control to make a no-code, designer friendly experience possible.

If someone would get serious about this, I guess they would take a look at the asp.net mvc approach. They also hook the url's you are setting, to the back button(!) So, there should be good crossbrowser javascript available.

Also, a good and flexible url parsing engine is necessary.

Finally, when you take the approach of one controller doing all the hard work, nothing much has to be done. However, I can see the creation of all kinds of specific classes that can be attached to controls to make them 'url-persistable' (think of selecting the right listbox item).

Try it out

The homepage of our sample application:
http://www.sitechno.com/silverlight/deeplinking/deeplinkingtestpage.html

Two url's with state in them:
http://www.sitechno.com/silverlight/deeplinking/deeplinkingtestpage.html#products/SqlServer/760
http://www.sitechno.com/silverlight/deeplinking/deeplinkingtestpage.html#help/309/1166

I will not keep this application available forever and probably not update it to the release version of beta2.

Who is going to make themselves useful by creating a robust solution? Leave a comment of mail me if you want the source code!

Okay, I've been busy with other stuff in my life, I'll blog about soon. Suffice it to say, I'm going to be able to focus my time more on Silverlight now ;-)

The Silverlight team is announcing beta 2 with this post. It's a pretty long list with changes, and it's looking very good! Here are a few of my favorites:

• They included some controls into the runtime. So more goodies without added download size.
• A visual tree helper. I'm looking for more information on this. As you know, SL does not have the same concept of a seperate visual tree and logical tree as WPF does. They instead opted to not differentiate. Does this helper mean that the two models come closer to each other?
• Per binding level validation.
• Binding to attached properties! Yay!
• OnItemsChanged method
• Fallback value during conversion
• Duplex communication. Oh dear, they really hit the sweet spot here. This allows you to push data to the client during a call.

The big one for me is support for UIAutomation though. I'm not sure if it is supported fully, but this means you can test your controls with actual 'human'-like input. I think this is important when building an application with a late-bound system like Xaml-binding.

The whole blogosphere is raving about the new VisualStateManager. It is a highlevel api to work with your states. The blend team is able to give you a much improved templating story because of it. Read about it here or here.

I've recently moved this blog to another host. Everything seems to work, except for access denied errors on the comments.

I'm using DasBlog which writes to the filesystem. I'm able to post new posts without problems, but comments don't work.

If you have any comments, feel free to email me. I've already received a few, and will be answering them.

[update: not sure why, but I removed the allcomments.xml, and there is no longer an error. However, no new 'allcomments.xml' file is created, so don't know what's up with that!]

Daniel Simmons commented on the next beta of EF where the team has worked with the WCF team to allow for better serialization (in an interoperable way) of complete graphs and relations. I'm very excited to hear that, but as Julie Lerman pointed out: it's also kind of frustrating for me. ;-)

As you know, I have 3 different pieces of technology that help make the possibility of n-tier disconnected scenario easy.

One of those pieces is the circular serializer, that was created to change the way WCF serializes circular references. However, it has grown to also support 'original' values.

My current plan is as follows:
I will wait to see how WCF serializes entity graphs in the next beta. I expect to see that my circular serializer is no longer necessary. Hopefully I will be able to remove it all together.
What will still be necessary though is getting the original values across the wire. So, I'll probably generate those properties inside of the classes themselves, negating the use of a surrogate serializer. Then, on the client, you will just be able to use your objects like before, and on the server you would notify the objectgraph of the need to fill the original values just before you return them. This might work out very well.

The use of a surrogate is actually what is stopping me from targeting Silverlight, so with a little luck, the changes in the next version will enable the use of Silverlight as well. I'm looking forward to it!

I just finished a small sample application that illustrates a client/server application using Entity Framework on the server and just regular objects on the client. The client has custom changetracking and the server is able to attach the graph to a context again. Source can be found at the efcontrib page, and I guess I'm almost ready to do a proper release!

[I used Prism to build the client in a Model View Controller approach. It was a fun exercise and I'm looking forward to seeing that project released.]

The application manages employees and allows for setting a 'teamleader' on an employee: think of 'is managed by'. I thought it would be cool to send that over the wire.

Here is a screenshot of the main view of the application:

As you can see, you can 'choose' an employee. When you press that button, you will see another screen where you can enter a lastname. It will fill a grid with employees matching that criteria and allows you to choose from that list.
It is also allowed to 'add an employee'. There are actually 3 types of employees you can add: Mort, Elvis and Einstein.

On the row of teamleader, you can again press the 'choose' button, which will allow you to set a relation between the employee you are editing and another employee.

On the server, there are a few methods like this:

You can see me taking care to call the 'prepareForSerialization' on each graph that I'm returning on line 10.

The client can just use these objects like normal.

I'll look into delving into it a bit with a screencast soon.