Idee: Silverlight und Code-Inside

[wolter]

Hallo zusammen,

ich habe mich mal mit dem fehlenden Code-Inside in Silverlight auseinandergesetzt (http://www.wolter.biz/2008/07/07/ide...d-code-inside/) und frage mich, ob es dafür überhaupt (noch) Bedarf gibt: Klar, man sollte Code und Design möglichst trennen, doch wenn ich mir die Praxis in der Flash-Welt anschaue, dann ist das wohl leider ein Wunschtraum von Softwarearchitekten. Zugegebenermassen führt ja auch gerade diese Vermischung von Code und Design dazu, dass Flash sich auch für kleinere Projekte eignet und gerne von "Nicht-Programmierern" eingesetzt wird.

Was meint Ihr? Und hat jemand von Euch schon mal XAML um eine "Nicht visuelle" Komponente erweitert, die sich vielleicht sogar zum interpretieren von Programmcode innerhalb XAMLs eignen würde?

Liebe Grüße,

Sascha.

[maximago]

In der Praxis hat sich selbst bei kleineren Projekten die Trennung bewährt. Wir haben zahlreiche Projekte realisiert und es hat optimal funktioniert. Im Detail betrachtet war der Ansatz bei WinForm ja ähnlich: Dort gab es auch schon eine Designer-Datei. Jetzt ist nun aber aufbohrt um die ganze Funktionalität (Animation, Vektor, 3D,...) und mit speziellen Tools versehen. Außerdem ist der neue Ansatz für Web und Software die gleiche Technologie verwenden zu können.

Für die Anpassung an einem eigenen UserControl oder selbst die Erstellung eines CustomControls ist übrigens kein Hexenwerk, das schaffen in den Grundzügen auch Designer wie ich es von Hause aus bin ;-)

[wolter]

Zitat von maximago

In der Praxis hat sich selbst bei kleineren Projekten die Trennung bewährt. Wir haben zahlreiche Projekte realisiert und es hat optimal funktioniert.

Das ist keine Frage. Aber Du sprichst hier auch von "wir". Vielleicht mal mit anderen Worten, was ich meinte: Es könnte reizvoll (damit meine ich nicht besser) für Einzelpersonen sein (die sich nicht mit Visual Studio und vergleichbar beschäftigen bzw. beschäftigen wollen), alles in Blend machen zu können.

Zitat von maximago

Für die Anpassung an einem eigenen UserControl oder selbst die Erstellung eines CustomControls ist übrigens kein Hexenwerk, das schaffen in den Grundzügen auch Designer wie ich es von Hause aus bin ;-)

Es geht nicht um einfache UserControls sondern um ein "nicht-visuelles Control", dass als Parameter einen Codeblock erhält, der dann interpretiert wird. Hier fände ich ein Beispiel spannend, da das über normale Controls hinaus geht und auch gleich noch die Verarbeitung einer "Dynamic Language" mit Silverlight 2 zeigt (letzteres ist dabei ja bereits gut dokumentiert). Vielleicht finde ich ja irgendwann mal die Zeit, das selber zu probieren .

Beste Grüße,

Sascha.

[maximago]

Ich muss gestehen den Sinn nicht ganz nachvollziehen zu können.
Mit den Express Editionen von Visual Studio muss man sich nicht mit dem ganzen Riesen-Apparat auseinandersetzen und hat eine Code-Optimierte Umgebung.

Wenn Du ein Control bauen willst, dem Du eine Property gibst, wo Du Code reinsetzen willst, dürfte das - so lange Du das zur Entwurfszeit machst - grundsätzlich nicht das Problem sein, schon gar nicht mit JavaScript.
Zur Laufzeit sieht das schon anders aus, Du müsstest ja dann zur Laufzeit kompilieren, ob das Silverlight kann, wage ich zu bezweifeln.
Aber da steig ich als Designer eh aus ;-)

Grundsätzlich nochmal zur Trennung von Design und Code auf Werkzeugebene: Die Entwicklung von Medien-Software hat gezeigt, dass die Bündelung von Funktion in einer einzigen Software zu schwer händelbaren Anwendungen macht. Beispielsweise ist Photoshop ein solches Monster geworden, dass Auszubildende Monate brauchen um auch nur etwas damit klar zu kommen. Die Hauptarbeit besteht nämlich darin, die für die gerade wichtigen Handlungen die notwendigen Funktionen von den gerade völlig unnötigen Funktionen zu filtern. Dreamweaver versucht das seit einiger Zeit durch die verschiedene Konfiguration der Oberfläche ("Code" oder "Design").
Und genau das Prinzip greift MS mit Blend und VisualStudio auf.
Und gerade in diesem Bereich, wo sich Designer und Programmierer begegnen (und seien wir ehrlich, unterschiedlichere Nutzergruppen gibt es doch wohl kaum), macht das einfach nur Sinn.
Dass vereinzelte Nutzer da aus dem Raster fallen, kann ich mir gut vorstellen, aber die Masse wird - davon bin ich überzeugt - dieses Konzept befürworten.

[wolter]

Ja, für die "normale" Entwicklung ist das sicher nicht zu empfehlen. Es geht mehr um die - im Flash-Bereich nicht so seltene - eierlegende Wollmilchsau, die alles vom Design bis zur Programmierung machen will. Klar, das klappt nur in den wenigsten Fällen wirklich überzeugend, aber dennoch ist der Bedarf da. Nur um das klar zu stellen: Ich würde selber nicht so arbeiten, fände die Mölglichkeit aber genau für diesen Typ "Entwickler" interessant. Denn genau das ist mit ein Grund, warum Flash am Anfang so erfolgreich war: Ein Enwickler erstellt mit einem Werkzeug recht schnell passable Ergebnisse!

Grüße,

Sascha.