Ivan Krivyakov's Blog

Learned something new today. It turns out in current incarnation of F# you can have “parametrized types”. Although it sounds like another flavor of templates, it is nothing like it. These are the types with “units of measure” attached. You can have weight value of type float divided by volume of type float to achieve density of type <kg/m^3>. E.g. 2.5<kg>/5.0<m^3> yields 0.5<kg/m^3>.

The measures exist only for F# compiler. They are “erased” when creating the IL code, so they can’t be queried at runtime. I am not sure yet how generic this can be made and what other applications besides physics it might have.

Let’s say I have a view that must open another window on command. Where would this code sit?

The model? Don’t be ridiculous.

The view model? Yes, it’s where the command handlers are, but view model is not supposed to know about the views, and this would not be testable.

The View? Well, maybe, but aren’t the command handlers in view model? Besides, the view may not have enough data to create the desired window.

I realized, that all WPF apps that I created so far had pretty much static UI defined at startup, and any simple dialogs that needed to be shown dynamically were created by a “dialog service”.

Surprisingly, quick googling gives very little insight on the topic, although it comes with with this answer and this article.

They seem to advise to create the views in a special layer (“controller”), talking to it via a service locator or an event broker. This kind of makes sense, because none of the 3 components of MVVM is well equipped for making new views. On the other hand, it is annoying, since it means one more moving part.

1. The view model shall never directly manipulate the controls..
2. The view shall never manipulate the model..

These are two negatives, because they govern the separation of concerns. Most other things in MVVM are corollaries of these two principles.

http://www.ikriv.com/demo/mvvm/

Now includes answers to questions asked during the presentation

I remember reading on Microsoft web site that although WPF and Silverlight are different technologies, their libraries will eventually converge.

While this might be a declared goal, it by no means is a high priority. I recently tried to quickly port my very simple WPF demo application to Silverlight 4. What did I find?

- There is no BooleanToVisibilityConverter. It’s a very simple and useful class, takes maybe 20 lines of code. They just did not care to include it.

- Label control is not in main Silverlight libraries, but in the “SDK”. Come on. I would understand if that was Calendar, or something else which is heavy and rarely used. But Label? This makes reusing XAML between WPF and SDK difficult, since Label is quite common, and in Silverlight it is sdk:Label.

- There is no IsDefault property on buttons. I am not sure, maybe keyboard handling is very different in SL. But still, looks very strange. Shouldn’t something happen when you press ENTER? Why can’t it be a button command?

- There is no Visibility.Hidden. Well, maybe that complicated layout management and they through it away, or something. Again, makes porting code difficult.

As I said, some of these differences may have deep rooted reasons, but BooleanToVisibilityConverter?! I will be very surprised if it’s something philosophical. They just did not give it a priority.
CodeProject