Sascha Wolter

Keine Frage, dass es bei großen Projekten nicht empfehlenswert ist, Code und Design zu vermischen. Doch in der Praxis macht gerade diese Vorgehensweise bei kleineren Projekten Sinn, da so die Erstellung

1. relativ einfach erlernt und
2. alles von einer Person in
3. einem Werkzeug umgesetzte werden kann.

Viele Sprachen wie HTML und Co. erlauben die Verknüpfung von Logik und Oberflächenbeschreibung in einer Datei. Ein gutes Beispiel für den Erfolg und die Gefahren dieser Vorgehensweise ist Flash. Denn Flash erfreut sich gerade dank dieser Vermischung einer recht steilen Lernkurve und erlaubt es auch Programm(ier)novizen, schnell zu Ergebnissen zu kommen. Doch wer hier nicht mit Disziplin vorgeht, findet seine Codeblöcke bei Problemen nur schwer in den zahlreichen Zeitleisten und Objekten wieder.

Softwarearchitekten wird es freuen, dass dieses Vorgehen in Silverlight nicht möglich ist und eine klare Trennung von Code und Design erzwungen wird. Denn Silverlight nutzt anstelle von Code-Inside Code-Behind. D. h. die Logik (z. B. C#) wird nicht mit der Oberflächenbeschreibung (XAML) vermischt sondern in eigenen Klassen platziert (partial classes) – anders als übrigens in WPF mit dem eigens dafür vorhandenen code Tag:

1
2
3
4
5
6
7
8
9

<Canvas xmlns...>
  <Button Name="button1" Click="Clicked">Click Me!</Button>
  <x:Code><![CDATA[
    void Clicked(object sender, RoutedEventArgs e)
    {
        button1.Content = "Hello World";
    }
  ]]></x:Code>
</Canvas>

So schön das in der Theorie klingt, führt diese Aufteilung in der Praxis zu einer flacheren Lernkurve und Erschwert die Erstellung durch eine Person mit einem Werkzeug. Nur wer sowohl Expression Blend für das Design als auch Visual Studio für den Code sein eigen nennt und zusätzlich auch beherrscht, kommt in annehmbarer Zeit ohne weitere Unterstützung zu guten Ergebnissen.

Doch Abhilfe sollte in Silverlight möglich sein. Die Unterstützung von dynamischen Sprachen ließe sich kombiniert mit einer entsprechenden Erweiterung in XAML durchaus dazu nutzen, sollte Microsoft nicht selber nachbessern (wie gesagt, in WPF ist das ja bereits enthalten). Diese XAML-Erweiterung müsste nur den mit ihr verbundenen dynamischen Code interpretieren und ausführen. Bereits vorhanden bzw. angekündigt sind Codebibliotheken für Iron Ruby, Iron Python, Visual Basic Script und JavaScript. Einzig die Integration in XAML fehlt noch.