Darstellung einer Initialisierungsphase in einer MDI-Anwendung

[Szdnez]

Hallo,

folgendes Szenario: Ich habe eine Flex-Anwendung, die wie eine klassische MDI-Anwendung aufgebaut ist (Mehrfenstersystem). Die einzelnen Fenster/Dialoge können z.B. über ein Menü geöffnet werden (es wird dabei jedes Mal eine neue Instanz des zu öffnenden Dialogs erzeugt, der Dialog selber erbt von Panel). Je nach Art des Dialogs kann es sein, dass erst Daten von einem Webservice geholt werden müssen, die dann bspw. in einer Tabelle angezeigt werden, bevor der Anwender mit dem Dialog interagieren soll. Desweiteren können in diesen Dialogen auch Webservice-Aufrufe erfolgen.
Da diese Aufrufe unter Umständen etwas länger dauern (0 bis < 10 Sekunden) würde ich gerne für diese Zeiten den Dialog für den Nutze "sperren" (es sollen in diesem Dialog keine Eingaben mehr möglich sein, Buttons nicht drückbar u.ä. und noch irgendetwas "zappelndes" (Sanduhr, Fortschrittsbalken, ...) angezeigt werden). Wie könnte man das am elegantesten lösen?
Meine Idee ist mit States zu arbeiten. Der Default-Zustand ist der eigentliche Dialog und dann noch einen Zustand, der bspw. eine Box mit halbtransparenten Hintergrund und einem Fortschrittsbalken, der über einen Timer periodisch angesteuert wird, über den Dialog legt.
Aber vielleicht hat ja noch jemand ganz andere Ideen oder Vorschläge zur konkreten Implementierung
Mit ist zum Beispiel noch nicht ganz klar, wie ich es schaffe, dass die Box des neuen Zustands über dem Default-Zustand liegt und nicht einfach als Kind unten angehangen wird.

[Omega Psi]

Also, rein von der Implementierung der View gesehen, ist das mit den States so vollkommen ok. Dafür sind sie da.

[Szdnez]

Dann soll es so geschehen. Danke!

[sytch]

hi,
ich würde eher die view auf

enabled = false

setzen und mit

CursorManager.setBusyCursor/removeBusyCursor

arbeiten...

[Omega Psi]

Der BusyCurser ist aber dann für alle Fenster relevant. Wenn nun mehrere Fenster parallel arbeiten würde ich versuchen, den Fortschritt pro Fenster zu visualisieren.

[sytch]

man kann ja bei mouseOut auf dem panel den cursor removen und bei mouseOver wieder adden, sofern der ladevorgang noch nicht abgeschlossen ist.

würde ich den states noch vorziehen...

[Omega Psi]

Einigen wir uns darauf, dass es von der Spec abhängt, was man machen muss

[sytch]

ja, klar, bin halt kein fan von states... gibt meist unschönes code-wirrwarr... dann lieber einen viewstack und so die verschiedenen "sichten" managen...

[Omega Psi]

In Flex 4 ist das gaaaaaanz anders Und wenn man das Handling von states vernünftig und nicht zu granular aufbaut, dann sind sie auch in Flex 2, 3 gut zu händeln.

ViewStacks sind in großen Anwendungen hingegen eher unbrauchbar.

Aber jeder nach seiner Fasson

[sytch]

ViewStacks sind in großen Anwendungen hingegen eher unbrauchbar.

das kann man nicht generell pauschalisieren.... aber wie du schon sagst, jedem das seine...

[Szdnez]

Zitat von sytch

hi,
ich würde eher die view auf

enabled = false

setzen und mit

CursorManager.setBusyCursor/removeBusyCursor

arbeiten...

Vorgaben habe ich keine. Ich werde einfach mal beide Varianten ausprobieren und schauen, welche mir besser gefällt. Wobei dein Vorschlag bestimmt ressourcenschonender ist, oder?

[Omega Psi]

Ja, der enabled ist auch fixer in der Umsetzung.

[Szdnez]

Ich habe mich jetzt mal an der Umsetzung mit den States versucht. Im Grunde funktioniert es auch, nur einige Kleinigkeiten bereiten noch Probleme.

Bisher leiteten sich die Dialoge aus Panel ab, wobei es eine Basisklasse gibt, von der meine konkreten Dialoge erben. Da für die Dialog-Entwickler (das muss nicht ich sein) das Sperren des Dialogs und alles was damit zusammenhängt transparent sein soll, sollte sich an diesem Handling auch nichts ändern. Aus diesem Grund habe ich mich für folgendes Gerüst entschieden:

• Es gibt eine Handling-Klasse, dir für die Steuerung der einzelnen States zuständig ist, die von Panel erbt
• Es gibt eine "Warte-Seite" (Box mit halbtransparentem Hintergrund und einem zentrierten Fortschrittsbalken)
• Die konkreten Implementierungen der Dialoge, die jetzt allerdings von Canvas erben

Ein Dialog wird einer Handling-Klasse als Kind hinzugefügt (ist damit der Default-Zustand: currentState = ""). Daneben ist ein Zustand definiert, der für die Darstellung der Warte-Seite zuständig ist. Damit die Warte-Seite über den eigentlichen Inhalt gelegt wird habe ich das Layout des Handlers auf absolute gesetzt (was besseres ist mir nicht eingefallen). Damit werden dann aber meine Padding-Angaben ignoriert, die ich im Dialog gesetzt habe. Deswegen verpacke ich den eigentlich Dialog zusätzlich noch in einer Box und versehe diese mit einem Padding. Das ganze funktioniert soweit auch.

Allerdings habe ich Probleme mit der Warte-Seite. Wenn ich z.B. die Breite und Höhe der Warte-Seite auf 100% setze zappeln immer die Scrollbalken (die Seite scheint mehr Platz haben zu wollen als im Innern des Panels verfügbar ist). Gleiches passiert, wenn ich die Styles top, left, right und bottom auf jeweils 0 setze (zudem es nicht funktioniert, wenn das Fenster Scrollbalken hat. Bereiche, die gerade nicht sichtbar sind werden nicht "verdeckt", wenn man zu diesen scrollt). Andere Variante ist die Breite und Höhe der Warte-Seite auf explizite Werte zu setzen. Dann ist aber das Problem, dass sich Größenänderungen am Dialog nicht auf die Warte-Seite auswirken (das müsste man aber über Binding in den Griff bekommen können).

Allerdings finde ich das ganze alles etwas kompliziert, deswegen die Frage, ob es nicht auch einfacher geht? Der Dialogentwickler soll einfach von einer bestimmten Klasse erben und dort seine Dialoggeschichten reinschreiben, ohne Rücksicht auf irgendwelche Zustände und Co. nehmen zu müssen. Und die Warte-Seite soll dann bei Bedarf einfach über den Inhalt des Dialogs gelegt werden, so dass dieser halbtransparent durchschimmert (vlt. geht es ja auch mit Effekten, ...) und der Fortschrittsbalken einigermaßen zentriert ist.

Ich hoffe, dass ganze ist einigermaßen verständlich formuliert. Ansonsten kann ich auch noch gerne Code posten.

[Szdnez]

Ich habe jetzt erstmal eine Variante gefunden, die den gewünschten Effekt erzielt. Ich habe den halbtransparenten Hintergrund aus der Warte-Seite entfernt. Stattdessen setze ich beim Zustandswechsel auf die Warte-Seite das enabled-Property des Dialogs (also der Inhalt) auf false. Die Optik ist sehr ähnlich und ich muss mir keinen Kopp darum machen, ob der Hintergrund der Warte-Seite auch den kompletten Dialog bedeckt. Jetzt gibt es nur noch die kleine Unschönheit, dass beim Scrollen des kompletten Dialogs der Fortschrittsbalken nicht zentriert bleibt. Aber darum kümmere ich mich morgen. Ansonsten bin ich auch ganz Ohr für anderweitige Ideen, Vorschläge, ...