Ich habe die folgende Panel-Komponente namens AdvancedPanel mit controlBarContent:
%Vor%Ich habe ein zweites Panel namens CustomAdvancedPanel erstellt, das auf dem AdvancedPanel basiert, da ich den controlBarContent
nicht neu deklarieren möchte %Vor%Dies funktioniert nicht, da der Status 'Bearbeiten' in CustomAdvancedPanel nicht entsprechend dem Compiler deklariert ist. Ich muss den Bearbeitungszustand in CustomAdvancedPanel.mxml wie folgt neu deklarieren:
%Vor%Wenn Sie CustomAdvancedPanel in einer Anwendungskomponente verwenden, wird ein leeres Fenster mit der Schaltfläche "Zur Bearbeitung gehen" angezeigt. Aber wenn ich darauf klicke, wird der "Extra edit button" sichtbar, aber der "Show in edit" Knopf in der controlBar nicht.
Wenn das CustomAdvancedPanel leer ist, ohne erneut erkannten Status und "Extra edit button" funktioniert das Panel gut.
Ich denke, das liegt daran, dass das State-Objekt, das in AdvancedPanel deklariert wurde, nicht mit CustomAdvancedPanel identisch ist. Daher ist der Status unterschiedlich, auch wenn sie denselben Namen haben. Jedoch. Ich kann die Zustände von AdvancedPanel in CustomAdvancedPanel nicht verwenden, ohne sie in mxml zu deklarieren.
Gibt es eine Möglichkeit, diese Art der Wiederverwendung von Staaten zu erreichen? Oder gibt es einen besseren Weg, um das gleiche Ergebnis zu erhalten?
Ich empfehle Ihnen, Sparks Skinning-Architektur zu verwenden, um Ihre Ziele zu erreichen. Da Skin-Zustände in der Host-Komponente vererbt werden, können Sie die gesamte Logik in OOP-Weise platzieren. Aber Skins werden immer noch doppelten Code enthalten :( Jedenfalls ist es besser als der doppelte Code aller Komponenten.
Also wird unser AdvancedPanel wie folgt aussehen:
%Vor%Und für CustomAdvancedPanel:
%Vor%Natürlich können Sie von der Panel-Klasse erben, aber ich habe den Beispielcode einfacher gemacht.
Und die Skins:
%Vor%Und:
%Vor%AFAIK Der Zustand der Komponente geht nicht auf geerbte Komponenten über. Denken Sie darüber nach - wenn das der Fall wäre (wenn Sie Zustände erben könnten), würde es das Leben wirklich kompliziert machen, wann immer Sie eine Komponente erweitern möchten; Sie müssten sich aller ererbten Zustände bewusst sein und nicht auf ihre Zehen treten.
Ich denke, es ist eine Einschränkung der OO-Programmierung, aber nicht genau, was genau. Ich bin kein Flex-Experte, aber ich habe es von einem objektorientierten Programmierstandpunkt aus betrachtet und hier ist, was ich denke, passiert:
Beachten Sie zunächst, dass Flex (oder eine beliebige OO-Sprache) beim Erstellen eines Objekts automatisch eine Kopie dieses Objekts UND eine private Kopie des übergeordneten Objekts erstellt, die wiederum eine private Kopie des übergeordneten Objekts usw. erstellt der gesamte Objektbaum. Das mag seltsam klingen, aber als Beispiel dafür, wenn Sie super () in einen Konstruktor schreiben, rufen Sie den Konstruktor der Elternklasse auf.
Flex hat, was es "Eigenschaften" nennt. Dies ist das Äquivalent von dem, was in Java ein privates Mitgliedsfeld (Variable) mit einer öffentlichen Getter- und Setter-Methode wäre. Wenn Sie
deklarieren %Vor%Sie sagen effektiv
%Vor%was wiederum das AS ist äquivalent zu sagen
%Vor%Der wichtige Teil, und das ist eine allgemeine Regel für Eigenschaften, ist, dass setStates eine öffentliche Methode ist, die jeder aufrufen kann. Das Status-Array selbst ist jedoch privat. Wenn Sie keine deklarieren, hat CustomAdvancedPanel keine Statuseigenschaft. Es gibt auch keine setStates- oder getStates-Methode. Da setStates / getStates jedoch öffentlich sind, erbt es sie von AdvancedPanel, so dass es funktioniert, als ob es diese Methoden hätte. Wenn Sie eine dieser Methoden aufrufen (get oder set states array), ruft sie tatsächlich die Methode auf, wo sie existiert , die sich in ihrem übergeordneten Objekt AdvancedPanel befindet. Wenn AdvancedPanel die Methode ausführt, wird der Wert von das states -Array in AdvancedPanel selbst gelesen oder gesetzt. Wenn Sie also in CustomAdvancedPanel keine Zustände neu deklarieren, funktioniert alles einwandfrei - Sie denken, dass Sie das states -Array in CustomAdvancedPanel setzen und abholen, aber tatsächlich hinter den Kulissen, die Sie im states -Array im übergeordneten Objekt "AdvancedPanel" betreiben vollkommen in Ordnung und gut.
Jetzt definieren Sie das states-Array in CustomAdvancedPanel neu - was passiert? Denken Sie daran, dass das Deklarieren einer Eigenschaft in Flex dem Deklarieren einer privaten Variablen auf Klassenebene und öffentlicher Getter und Setter entspricht. Sie geben also CustomAdvancedPanel ein privates Array namens states und öffentliche Getter und Setter, um dieses Array zu erhalten / setzen. Diese Getter und Setter überschreiben diejenigen von AdvancedPanel. Nun wird Ihre Anwendung auf die gleiche Weise mit CustomAdvancedPanel interagieren, aber hinter den Kulissen arbeiten Sie nicht mehr mit den Methoden / Variablen von AdvancedPanel, sondern mit denen, die Sie in CustomAdvancedPanel selbst deklariert haben. Dies erklärt, warum, wenn Sie den Status von CustomAdvancedPanel ändern, der Teil, der von AdvancedPanel geerbt wird, nicht reagiert, da seine Anzeige mit dem states -Array in AdvancedPanel verknüpft ist, das immer noch unabhängig existiert.
Warum ist das IncludeIn nicht im Basisbeispiel erlaubt, in dem Sie die Zustände nicht neu deklarieren? Ich weiß es nicht. Entweder ist es ein Fehler, oder vielleicht eher, es gibt einen legitimen Sprach- / OO-Grund, warum es niemals funktionieren könnte.
Es ist möglich, dass meine Erklärung nicht genau ist. So weit ich die Dinge verstehe. Ich weiß nicht, warum das wirklich passieren würde, wenn man bedenkt, dass der fragliche Button Teil der Superklasse ist. Ein paar interessante Tests wären:
Wenn Sie mehr über all diese Vererbungstypen erfahren möchten, schreiben Sie einige einfache Klassen in ActionScript oder Flex mit einer Klasse, die eine andere erbt, und führen Sie verschiedene Funktionsaufrufe aus, um zu sehen, was passiert.
"Oder gibt es einen besseren Weg, um das gleiche Ergebnis zu erhalten?"
Da Sie gefragt haben, und weil Sie keinen klaren Fall bezüglich der Notwendigkeit für die zusätzliche CustomAdvancedPanel-Komponente gemacht haben, ist die "Extra Edit-Schaltfläche" in der AdvancedPanel-Komponente die einfachste Lösung.
%Vor%Natürlich ist der politisch korrekte Weg, Skins zu verwenden. Aber für diejenigen, die wirklich nur staatliche Statusvererbung für MXML-Klassen wollen, ist hier eine Arbeit, die ich gefunden habe.
Damit diese Methode funktioniert, sollte die erweiterte MXML-Klasse genau dieselben Zustände der Basis-MXML-Klasse deklarieren, nicht mehr und nicht weniger, alle mit identischen Namen.
Fügen Sie dann in der Erweiterungsklasse die folgende Methode ein:
%Vor%Dies funktioniert, da die states-Variable beim Erstellen der Komponente zweimal festgelegt wird, einmal von der Basisklasse und einmal von der erweiterten Klasse. Diese Problemumgehung fasst sie nur zusammen.