Menu in Silverlight 2.0

[Norbert66]

Moinmoin,

gerade versuche ich meine erstes Progrämmchen in Silverlight 2.0 zu bauen. Dabei muß ich feststellen, das es garnicht das <Menu>-Control gibt, wie es bei WPF vorhanden ist.

Wie kann ich ein normales Hauptmenü erstellen ?

Gruß
Norbert

[Gerhard Jaros]

Ein Menue im Sinne eines WinForm-Menues gibt es in Silverlight 2 nicht. Silverlight ist ja auch dazu gedacht, Web-Applikationen zu erstellen. Ob uns Microsoft irgendwann die Moeglichkeit zu Menues gibt, kann ich nicht beantworten.

Jedoch ist es nicht sehr schwer, ein Menue zu simulieren. Dazu reicht ein StackPanel mit horizontaler Anordnung, eine Reihe Buttons, die als Haupt-Menuepunkte dienen und bei Click ein MenuePopup oeffnen, denn das gibt es in Silverlight.

Gerhard Jaros
EPS Software GmbH

[Norbert66]

Hi Gerhard,

das habe ich meinem Chef auch schon gesagt, das Silverlight eher für Web-Anwendungen gedacht ist. Aber ermöchte unbedingt, dass die alte C++-Software, welche u.a. eine größere Anlagen (SPS) ansteuert und recht umfangreiche datenbankorientierte Funktionalitäten (z.B. Produktionsplanung, Warenwirtschaft) umfaßt, komplett aufs "WEB 2.0" gehoben wird und es nur noch WebClients und keine Windowsclients mehr geben soll.

Gute Idee, hab gerade schon ein einfaches Menü für den Prototypen gebastelt.

Die Argumentation fürs Web sind:
1. Keine Clientseitige Installation notwendig
2. Es gibt ein oder zwei Kunden, die verteilte Betriebsstätten haben und dann auch per WEB-Anwendung direkt auf ihre Anlagen oder betriebswirtschaftlichen Daten zugreifen können.

Meiner Ansicht nach ist dieser Weg zwar möglich, aber nur mit enormen Mehraufwand. Einen Sinn darin sehe ich überhaupt nicht.

Gruß
Norbert

[robert.oh.]

Hallo Norbert,

Ein Nachteil von einer Webanwendung ist jedoch, dass laufend eine aktive Verbindung zum Internet bestehen muss.
Wenn es 'nur' um die beiden oben genannten Argumente geht, wuerde sich eventuell auch eine Click-Once Applikation anbieten.

Die Vorteile dieser Art waeren dann (kurz zusammgefasst):
- Volle Win32 Funktionalitaet (keine Einschraenkungen, wie 'fehlende' Menues, Sessions, ...).
- Der User navigiert zu einer URL und laedt sich die App automatisch herunter
- dadurch entsteht der naechste Vorteil, die App kann sogar offline laufen (Datenabgleich muss manuell geschrieben werden).
- Updates lassen sich ebenfalls einfach verteilen - einfach auf den Server und jeder Client bekommt (sofern eingestellt) beim naechsten Start seiner App die neue Version.
- ...

[Norbert66]

Hi Robert,

gute Argumente, aber wie sage ichs meinen Kindern

Als weiteres Argument für eine Webanwendung ist laut unserer Entscheidungsträger, das es verschiedene Scanner und andere Smartdevices (z.b. Kommissioniercomputer) schon mittels WebClient am bisherigen (C++)System angebunden sind.

Meiner Ansicht nach spricht trotzdem alles für einen normalen Windowsclient, welcher mit ClickOnce (gute Idee von dir) installiert wird. Für die speziellen Anwendungsfälle, können einfach entsprechende WebService oder Windowsdienste bereitgestellt werden, welche dann in WebClients präsentiert werden.

Auch bei verteilten Betriebsstätten sehe ich eher den Bedarf von der Zentrale verschiedene Information abrufen zu können oder meinetwegen auch mal eine Bestellung übers Netz zu einer anderen Betriebsstätte zu übertragen.

Grundsätzlich muss es sowieso bei jeder Betriebsstätte einen eigenen Datenbankserver geben, da nur Offline ein mechanische Anlage (SPS) sicher gesteuert werden kann. Für Chefauswertungen wäre es da mit sicherheit besser, wenn die Daten der verschiedenen Betriebsstätten im zeitlichen Zyklus abgeglichen oder in ein zentrales DataWarehouse gepackt würden.

Mal schauen wie der Entscheidungsprozess ausgeht... teuer, hypermöchtegernmodern oder schlank, flexibel und mit "Best Practice".

Gruß
Norbert

[robert.oh.]

Mir scheint, du hast ein paar 'anregende' Diskussionsstunden / -tage vor dir.

Viel Spass dabei

[Norbert66]

Jo danke, das wird wohl noch ein paar heiße Diskussionen geben. Habe vorhin schon mal einige Kilobytes an vergleichen zwischen den verschiedenen Clienttechnologien runtergetippt.

Sachlich fundierte Argumente habe ich reichlich und auch einen mehrschichtigen Prototypen realisiert, der 5 verschieden Clients (Consolen, WPF, WinForms, ASP, WPF), LinqToSql, Bussinessklassen, zwei Services (REST, SOAP), Konfiguration über web.config/app.config, Scriptcompiler für C#, Klassen über Reflection analysieren und einiges mehr implementiert. Immer soweit das die kritischen Stellen geklärt waren.

Im Bereich der WebClients kommt man bei komplexeren Szenarien sehr schnell an die Grenzen des sinnvoll und wirtschaftlich machbaren. Auch das was unter dem Marketingbegriff WEB 2.0 verkauft wird, ist absokut ungeeignet für eine komplexe, datenbanklastige Branchensoftware mit der auch noch komplexe Anlagen angesteuert und Visualisiert werden sollen.

Es gibt kein technisches K.O.-Kriterium für einen Silverlight-Client. Jedoch steigt die Komplexität durch die große Menge an Services enorm. Das wäre nur vertretbar, wenn es sich um eine Anwendung handeln würde, die wirklich weltweit im WWW verfügbar sein soll. Aus wirtschaftlicher Sicht gibt es ein eindeutiges K.O., weil es keinen Mehrwert für den Kunden darstellt und die Verkaufspreise nicht entsprechend des Mehraufwands an die Kunden weiter gegeben werden kann.

Gruß
Norbert