Translate C# WPF Applications to HTLM5 with WPF.polymer Part II – Business Logic

Since more and more people show interest for this topic/posts and I just discovered a question on Stackoverflow mentioning this blog there is no more room for excuses – I owe you a second part. So I will just start and see how far I can come this time…

Last time, I showed you that XAML which is rendered into beautiful UIs is just a XML dialect and that we can use this knowledge to transform it into another XML representation: (X)HTML.

There was just one problem: our browser does not know about any WPF tags but instead speaks div, span, etc… But with Polymer to the rescue we were able to teach our browser how to read, simulate and render XAML. This allowed us to reuse our existing Desktop UI and display it in a modern browser.

But this was just a cool side effect and not what we really wanted. I promised you more: write code once and run it everywhere (smartphone, web, mac, linux)

Current State

So where are we now? We have an application that is written in C# and a UI written in WPF. We know, that we can translate the UI into XHTML and render it in a browser with WPF.polymer.
We are here:
Step1
So the next question that we might want to ask is: how do we get the C# code onto multiple platforms? And there is an easy answer for this: with a virtual machine that runs on every platform. And this virtual machine is provided by the Mono project.

The stated purpose of Mono is not only to be able to run Microsoft .NET applications cross-platform […]. Mono can be run on many software systems including Android, most Linux distributions, BSD, OS X, Windows, Solaris, and even some game consoles such as PlayStation 3, Wii, and Xbox 360.

Source: Wikipedia

And even better news is, that recently, Microsoft declared that they want to move cross platform and want to open source code of their .NET framework!!

Why do we open source .NET Core?
There are two big reasons why we decided to open source .NET Core:

  • Lay the foundation for a cross platform .NET
  • Build and leverage a stronger ecosystem


MSDN Blog

Cross Platform Reality

Ok great! So then we are all set, right? Unfortunately not.

We are just here:
cross-platform-2

If you compare diagram 1 & 2 you will recognize some changes in color. That is because I wanted to make one thing clear: in order to run on multiple devices, both generated codes need a virtual machine. For the C# code it’s Mono and for the Web UI it’s a browser. So both parts are running in their own(!) encapsulated environment. What’s missing is the communication.

And this is not the only problem. In fact, it would be a bad idea to try starting a browser, then navigate on a page that displays the generated UI and start the code that drives the page in its own vm context. And for this reason, we need a way to merge both worlds first…

The Chromium Embedded Framework (CEF)

First things first, what is CEF?

The Chromium Embedded Framework (CEF) is an open source framework for embedding a web browser engine based on Chromium. It is a convenient way to add web browser control and implement an HTML5 based GUI in a desktop application […]

Source: Wikipedia

I want to repeat: “HTML5 based GUI in a desktop application” doesn’t that sound like a perfect fit for us? 😉

With CEF, we have our own “little” instance of a Chrome browser at hand. This means, we can render HTML, run Javascript from within our C# code and therefore have control over what is going on in the browser. Moreover, since we now have a modern(juhu!) webcontrol we can enjoy full support for modern web frameworks, HTML5 specifications, Web Components, Polymer, and don’t have to worry about how to support IE6.
We are getting closer!
cross-platform-3

Architecture Cut

That was a lot of preparation work. And I wish I could tell you now “you’re good to go” but the tricky part has just started.
We need to find a cut in our architecture. And the reason for this is, that our UI is actually broken:

Chances are good that you have something in your UI code that looks like the markup in above listing. As you can see, UI often contains things like click events or commands. Without them, we only have a static mask. Interaction through event is what brings live into our GUI.

The code-behind file defines the UI behavior. Users can modify the state of the View with certain actions. Changes in state lead to changes in appearance of our View. And there are some patterns, guidelines and frameworks that even say that code-behind files should ideally be empty. All in all, there is not one right way to create GUIs. GUIs are damn complex. And Visual C# has some advanced mechanisms, running behind the curtain, that are hiding how markup and code-behind are wired up. It just works in our IDE. And this is the big problem now.
Because when we translate the XAML to HTML there aren’t these cool mechanisms. All the click events and commands are becoming attribute garbage. And even if it would be possible to keep the events and forward them to our C# backend we would end up with a weird architecture, huge latency issues and other problems.

And for this reasons we will let things stay together that are meant to be together. We need to cross compile some C# code into JavaScript, glue it magically together, like it was done for us and wire it to our business app core, running in on the “backend”. And depending on how good or bad our application design was, this part can get really, really ugly!

Next time I will show you my C# to JS cross compiler and guide you through the steps, needed to reproduce my proof of concept. Moreover, I will go into more detail on how to cut your architecture and the role of MVVM.

4 thoughts on “Translate C# WPF Applications to HTLM5 with WPF.polymer Part II – Business Logic

  1. Just curious to know when the next blog post is coming showing your c# to js cross compiler 🙂 It looks very interesting.

  2. I’m currently checking your work on WPF Polymer, and implementing some more controls such as the TextInput As a proof of concept it works nicely, however when used with actual production code lots of things break, for instance correctly capturing change() or keyup() events due to the shadow DOM used by Polymer. Really interested to see what your c# to JS converter does.

    1. Great! I’ll push the rest of this experiment to github and write a little intro about it.
      It probably makes sense to check for changes since both, roslyn and polymer had some major revision updates in the meantime

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload the CAPTCHA.