VisualStateManager: Gut oder böse?

Es gibt keine Trigger in Silverlight. Also weder zum Auslösen von Storyboards (gut, bis auf ein paar fast Unbrauchbare), noch Data.Trigger oder Styles.Trigger.

Statt dessen gibt es eine neue Systematik: Den VisualStateManager. Die Idee dahinter ist folgende: Der Entwickler definiert in seinem Control die benötigten UI-Elemente. Z.B. ist für ein Drop-Down-Control definiert, dass es ein PopUp beinhalten muss. Der Entwickler teilt also in einem "Control Contract" dem Designer mit, welche Controls er gefälligst einzubauen hat, damit das Control funktioniert. Soweit so gut.

Dieser Mechanismus ist tatsächlich transparenter als in WPF, wo der Designer nach Elementen mit der Benennung "PART_..." Auschauhalten muss. Neben den empfohlenen UI-Elementen, definiert der Entwickler auch die verfügbaren States des Controls. Er ist auch verantwortlich dafür, wann welcher State aufgerufen wird, und ob Transitions verwendet werden sollen. Der Designer kann dann einfach die States isoliert designen und muss sich über den Wechsel der Stati keine Gedanken machen.

Und genau da kann man (wie ich es auch tue) einen Hacken sehen. Denn er muss sich darüber keine Gedanken machen, KANN es aber auch nicht. Dem Designer sind alle Möglichkeiten genommen das Verhalten des Controls zu beinflussen. In WPF kann der Designer beispielsweise über Property-Trigger selbst bestimmen wann was passieren soll. Diese Möglichkeit ist ihm in Silverlight genommen.

Warum wurde denn dann überhaupt der VisualStateManager in Silverlight implementiert? Eine Vermutung liegt mehr als nahe: Es ist ein Workaround, um die fehlenden Trigger in Silverlight irgendwie wett zu machen. Unschönerweise wird das nun auch noch als "Plus" verkauft und so sehr dazu gestanden, dass der VisualStateManager sogar Einzug in .NET 4 erhalten wird. Ob das wirklich die richtige Strategie ist, sei dahin gestellt...