Edytor schematów.

[Filip Matuszewski]

Hej.
Piszę edytor schematów we flex chciałbym podzielić się z wami swoimi pomysłami oraz spytać o opinię co o nich sądzicie.
Definicja problemu:
Stworzyć hierarchiczny edytor schematów. Schemat składa się z komponentów które mogą być połączone ze sobą linkami ( więzami).
Każdy element może mieć kilka portów do których można podłączyć więzy.
Można łatwo wyobrazić sobie implementację w postaci edytora grafów uml, czy schematów baz danych.

Chciałem zrealizować to w następujący sposób.
Klasy:
Canvas - obszr roboczy kontener w którym mogą być rozmieszczane elementy
Component - każdy element który może być umieszczony w Canvas
Port - jest częścią Component. do portów można podłączyć Constraint.
Constraint - więzy reprezentowane w postaci lini łączącej dowolne 2 porty.

1 Jak rozmieszczać objekty Component w kontenerze Canvas.
Zastanawiałem się nad wzorcem DECORATOR która będzie implementowała operacje resize drar rotate.
Niestety klasa Komponent jest bardzo skomplikowana. To znaczy ma zdefiniowanych wiele metod i atrybutów, których nie chcę implementować w klasie DECORATOR. Wystarczy jeżeli będę przekazywał atrybuty odpowiedzialne za położenie wymiary oraz obrót.

Chcę móc defniować różne podklasy klasy Component. Chciałem także aby w zależności od typu można było modyfikować inne atrybuty przy pomocy mojego DekoratoraComponentów, ale informację o tym jakie operacje mogą być wykonywane chciałbym przechowywać poza obiektem Component.
Chodzi o to że mam gotowe podklasy różnych komponentów jak przyciski i suwaki etc. których nie chcę rozszerzać.

Myślałem nad następującym rozwiązaniem Stworzyć
ComponentController - Kontroler który będzie odbierał wszystkie zdarzenia kliknięcia komponentu od Canvas.
kontroler ten będzie posiadał referencję do
ComponentDecoratorBuilder - będzie ona tworzyła różne instancje Dekoratorów w zaleśności od typu podklasy klasy Component wysyłającej zdarzenie(event).
ComponentController - będzie umieszczał ten dekorator na canvas i wiązał go z Klikniętym Componentem.
Czyli reasumując
1.Klikamy Komponent
2.Komponent wysyła zdarzenie że ktoś go kliknął.
3.Zdarzenie odbierane przez ComponentController i przekazywane do ComponentDecoratorBuilder.
4.ComponentDecoratorBuilder sprawdza typ podklasy która wysłała zdarzenie i buduje odpowiedni Decorator i zwraca go do ComponentController.
5.ComponentController umieszcza ComponentDecorator w Canvas i wiąże go z Komponentem.

6. Po kliknięciu w canvas ComponentController usuwa ComponentDecorator z Canvas.

Jakie są wasze opinie?
Nie mogę stworzyć Decoratora jako podklasy klasy Component gdyż nie mogę (nie chcę) implementować wszystkich metod.Zatem jak nazwać taką klasę?

Drugie zagadnienie trudniejsze dla mnie:
Po zmianie położenia komponentu muszę odrysować wszystkie Constraints (połączenia) między portami.
Jak odrysować linki powiążane z przesuniętym Komponentem
Nie chcę za każdym razem rysować wszystkich Contstraints.(powiązań.)

Flex Implementuje Komponenty w postaci klas z rodziny GLYPH
A zdarzenia są rozprowadzane zgodnie ze wzorcem CHAIN OF RESPONSIBILITY łańcuch zobowiązań.
Z tym że zdarzenia mogą być propagowane w dół i w górę drzewa (bubling)

Dlatego myślałem o takim rozwizaniu.
1 Po zmianie położenia Comonent wysyła zdarzenie informujące o zmianie położenia w dół drzewa.
2.Dzieci Porty odbierają to zdarzenie.i wysyłają zdarzenie w górę drzewa.
3.Kontroler zbiera te wszystkie zdarzeni i na tej podstawie wie które porty zmieniły położenie i które muszę być odrysowane.
zastanawiam się czy to rozwiązanie nie będzie zbyt zasobożerne.

a może po prostu wysłać zdarzenie przez przesunięty komponent.
i w Kontrolerze wyłuskać wszystkie porty.
to rozwiązanie nie podoba mi się o tyle że Porty mogą być zagnieżdżone w Komponencie kilka poziomów.
Komponent w komponencie.
W każdym Komponencie Port może znajdować się na innym poziomie hierarchii.
W związku z tym będę musiał implementować przechodzenie po tej hierarchii co nie podoba mi się za bardzo.


Co sądzicie ?
A może jakieś inne pomysły.
Założenia są takie że nie mogę dodawać funkcji zdarzeń do klas Component.
Tylko Do portów i kontrolerów.

Kolejna kwastia.
Jak zamodelować powiązania.

Tutaj także jest sporo możliwości.
Uznałem że można reprezentować połączenia między portami jako graf nieskierowany.
Graf nieskierowany może być reprezentowany przez.
Macierze.
-macierz o wymiarach AxA gdzie A to liczba wierzchołków.
wartość 0 na przecięciu wierzchołków oznacza brak połączenia 1 oznacza połączenie.
-
Listy powiązane.
-każdy wierzchołek dysponuje listą powiązanych z nim wierzchołków.
-z tym że każde powiązenie musi być reprezentowane dwa razy w obu wierzchołkach.

Lista krawędzi
-przechowująca referencje do obu wierzchołków.

No i oczywiście jak zapisywać i odczytywać te struktury do i z pliku.

To także zależy od sposobu implementacji.

Jak zapisywać powiązania.
Prawdopodobnie także będzie przydatny wzorzec VISITOR..

Uff trochę tego jest.
Może powinienem podzielić tą wiadomość na kilka wątków ?

Filip Matuszewski.

[Krzysztof Grajek]

Ja ze swojej strony może na początek zapytam czy technologia (flex) to juz przesądzone? Osobiście unikałbym 'reinventing the wheel' i zaczął kombinować z Eclipse RCP + EMF (eclipse modeling framework), nie wiem jak to dziala przez JNLP czy też w wersji 'RAP' ale jezeli nie jestes 'skazany' na flex'a to temat warty rozpoznania.

Pozdrawiam
Krzysztof Grajek

2011/12/6 Filip Matuszewski <filip.ma...@gmail.com>

[Filip Matuszewski]

Jest to praca inżynierska więc jak najbardziej wskazane jest w tym przypadku 'reinventing the wheel' gdyż bardziej chodzi o nauczenie się czegoś. Zdecydowałem się także na flash ze względu na to że bardziej od JNLP przyjął się w przeglądarkach intermetowych i jest po prostu bardziej powszcechny niż Java (w przeglądarkach).
Gdybym zdecydował się na Javę także starałbym się napisać rozwiązanie od począdku bez wykorzystania Eclipse RPC + EMF.
Acz kolwiek rzeczywiście biblioteki bardzo ułatwiają tworzenie tego typu aplikacji i prawdopodobnie warto jest zerknąć w ich kod źródłowy by zorientować się jak zostały napisane.