AST - Faza druga (sytuacje błędne)

Znalazłem dziś chwilę czasu którą postanowiłem poświęcić na wznowienie budowy mojego pierwszego edytora tekstowego.

Do utworzenia wstępnego szkicu gramatyki posłużyłem się specyfikacją pierwszej wersji języka xpath którą możesz znaleźć tutaj. Jednak gramatyka utworzona w ten sposób nie jest wystarczająca by zastosować ją jako serce edytora tekstowego. Dlaczego? Ponieważ buduje ona poprawne AST tylko dla poprawnego źródła, te jednak w naszym przypadku przez większość czasu zawiera błędy. W trakcie edycji niejednokrotnie następowałaby utrata struktury AST wymaganej do synchronizacji modelu wewnętrznego. Bez modelu natomiast nie bylibyśmy w stanie oznaczyć powstałych błędów, utworzyć listy podpowiedzi etc. Poniżej postaram się zaprezentować opisaną sytuację wraz z przykładową korektą gramatyki.

Do testu posłuży nam proste wyrażenie:

doc("Elementy")//elementA/elementB/elementC



Jak widać drzewo AST jest łatwe do dalszej analizy. Co wydarzy się jednak gdy użytkownik postanowi dodać predykat wybierający instancje 'elementA' spełniające określony warunek? Sprawdźmy jak wygląda sytuacja po dodaniu pierwszego znaku '[' (modyfikacja zaznaczona kolorem).

doc("Elementy")//elementA[/elementB/elementC



Jak widać parser całkowicie się pogubił, całość utrudniła możliwość wystąpienia podwyrażenia absolutnego w ramach predykatu. W wyniku tego w poszukiwaniu nawiasu zamykającego parser zjada nam resztę wyrażenia. W tym momencie zmuszeni bylibyśmy zaznaczyć połowę tekstu jako błędną co nie wyglądałoby zbyt estetycznie nie wspominając o braku podpowiedzi etc. Spróbujmy wybrnąć z tej sytuacji inaczej.

Ponieważ w samej gramatyce nie bardzo jesteśmy w stanie ocenić w jakim miejscu powinien znaleźć się nawias zamykający, zastosujemy mechanizm auto edycji (IAutoEditStrategy) który dołoży go zaraz za wstawianym przez użytkownika nawiasem otwierającym. Podobne działanie można zobaczyć w wielu edytorach w środowisku Eclipse. Poniżej możemy zobaczyć wynikowe wyrażenie wraz z odpowiadającym AST (modyfikacja zaznaczona kolorem).

doc("Elementy")//elementA[]/elementB/elementC



Na drzewie ponownie możemy zobaczyć utracone wcześniej elementy jednak całość jest nadal bezużyteczna. Powodem jest brak obsługi pustych predykatów w naszej gramatyce które nie są poprawnymi elementami wyrażenia. Ponieważ jednocześnie chcemy by nasz parser potrafił sytuację obsłużyć poprawnie oraz oznaczyć miejsce błędu zastosujemy wirtualny token 'ERR_EMPTY_PREDICATE_TOKEN' (modyfikacja zaznaczona kolorem).

predicate
     : '[' expr ']' -> ^(PREDICATE_TOKEN expr)//;
     | '[' ']' -> ^(PREDICATE_TOKEN ERR_EMPTY_PREDICATE_TOKEN);


Poniżej zobaczyć możemy wynikowe drzewo AST:



Jak widać pierwsza sytuacja błędna została opanowana. Pozostało 99 kolejnych którymi będę musiał się zająć gdy znów znajdę czas wolny. Pozdrowienia.

Platforma Swordfish - Analiza część 1

Postanowiłem sobie zrobić przerwę w nauce budowy edytorów tekstowych i zapoznać się z platforma Swordfish o której pisałem tydzień temu.

Aktualnie trwają prace nad przeniesieniem projektu na serwery Eclipse jednak od kilku tygodni kod przekazany przez firmę SOPERA dostępny jest w Bugzilli - 'Bug 211984'. Udostępniony pakiet zawiera definicję serwera zbudowaną na standardowym WST Server.

Jako projektów modułów platforma używa ciekawego połączenia standardowego projektu pluginu (Equinox) z projektem aspektowym. O zaletach takiego podejścia nie muszę chyba przekonywać nikogo kto choć raz rozbudowywał WTP o nowe definicje serwerów na bazie serwerów istniejących. Tym samym w projekcie nie znajdziemy natury PDE ale aspekty: 'java' (1.4,5.0) oraz 'osgi.swordfish' (1.0)..

Ponieważ platforma nie zawiera jeszcze kreatora takich projektów poniżej przedstawiam operacje jakie należy wykonać na standardowym projekcie pluginu (Equinox) by zadziałał na platformie Swordfish:
  • usuń naturę PDE wraz z odpowiadającymi jej kompilatorami


  • <nature>org.eclipse.pde.PluginNature</nature>
    <buildCommand><name>org.eclipse.pde.ManifestBuilder</name></buildCommand>
    <buildCommand><name>org.eclipse.pde.SchemaBuilder</name></buildCommand>

  • dodaj naturę projektu aspektowego


  • <nature>org.eclipse.wst.common.project.facet.core.nature</nature>
    <nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
    <nature>org.eclipse.jem.workbench.JavaEMFNature</nature>

  • Ustaw odpowiednie aspekty


  • Do ustawienia aspektu 'java' możesz użyć kreatora jednak próba ustawienia aspektu 'swordfish' zakończy się niestety aktualnie błędem delegata instalacji. Kreator utworzy jednak standardowy plik konfiguracji z aspektem 'java' do którego wystarczy dodać drugi aspekt (możesz oczywiście skopiować od razu gotowy plik):

    <installed facet="osgi.swordfish" version="1.0"/>

Po takiej modyfikacji twój plugin napisany dla platformy Equinox powinien bez najmniejszego problemu zainstalować się także na platformie Swordfish.

AST - Faza pierwsza

Jako egzemplarz testowy wybrałem sobie dość złożone zapytanie zawierające przekrój przez mechanizmy wyrażenia selekcji języka xpath:

doc("customers")[@name = 'g.bialek']//account[parent::type = 'personal']/@id

Zawiera ono następujące elementy:
- oczywiście ścieżkę z kilkoma krokami
- wywołanie funkcji dostępu do danych
- predykaty (prosty i z wyrażeniem relatywnym)
- osie (dziecko, dziecko zagnieżdżone, ojciec, parametr)

Poniżej widok na AST:

Platforma Swordfish

Dziś na wielu serwisach informacyjnych pojawiła się zapowiedź technologii która może stać sie krokiem milowym w rozpowszechnieniu OSGi jako platformy dla aplikacji biznesowych.

Mowa o platformie Swordfish która właśnie rozpoczyna swój żywot jako produkt open-source kontrolowany przez firmę SOPERA. Co to za projekt? Jest to platforma uruchomieniowa budowana zgodnie z modelem OSGi na bazie Equinoxa której zadaniem jest połączenie cech JBI oraz SCA. Nie wgłębiałem się na razie zbytnio w temat jednak po rozmowie z jednym z ich architektów podczas Eclipse Summit Europe - głosuję obiema rękami na 'TAK'. I to wcale nie z powodu jaskrawo zielonego plecaka który dostałem, po prostu moim zdaniem to krok do przodu i to w wyjątkowo dobrym kierunku ;D

Nowe wyzwanie

Kilka miesięcy temu przeczytałem ciekawą książkę o tworzeniu gramatyk. Uświadomiła mi ona że w ciągu ostatnich czterech lat pracy nad rozwiązaniami bazowanymi na platformie Eclipse nigdy nie pisałem edytora tekstowego. Brzmi to nieprawdopodobnie ale to prawda. Pracuję od kilku lat nad narzędziami używanymi głównie przez analityków biznesowych a co za tym idzie projektuję rozwiązania graficzne, strukturalne etc. Głównym ich założeniem jest łatwość obsługi która z oczywistych względów wyklucza stosowanie edytorów tekstowych. Postanowiłem jednak spróbować swoich sił i uzupełnić brakujący klocek w moim wielkim puzzle.

Za cel wybrałem sobie stworzenie komponentu umożliwiającego budowanie wyrażeń selekcji. Zadanie "klasyczne" które robiłem już kilkukrotnie w ramach rożnych projektów komercyjnych, Tym razem jednak nacisk postanowiłem położyć nie na cel biznesowy i czas ale na kompletność i łatwość integracji z rożnymi platformami. Trochę bardziej akademicko niż zazwyczaj ;D

Jako systemy docelowe wybrałem projekty: BPELDesigner, edytor integracji ESB oraz własne rozwiązanie komercyjne. Komponent w zamierzeniu powinien potrafić zbudować wyrażenie z pełną asystą dla użytkownika korzystając z każdego dostępnego źródła metadanych jakie wybrane projekty posiadają.

Na razie jestem w fazie projektu. Mam nadzieję że uda mi się przezwyciężyć własne lenistwo, brak czasu, bariery korporacyjne etc. Szkoda że nie pracuję w Google bo mógłbym zająć się takim projektem każdego piątego dnia tygodnia zamiast po godzinach ;D