Podczas prezentacji oprócz naprawdę fajnego demka z szachami wyjaśniona została także architektura samego projektu. Przyznam że bardzo podoba mi się zastosowanie Google Guice jako sposobu na kastomizację generatów. Łączenie kodu generowanego z ręcznie pisanym zawsze stanowiło duży problem w projektach o większym stopniu złożoności niezależnie od zastosowanego podejścia. Zwykle kończyło się to albo dziesiątkami metod 'generated NOT' albo było skrajnie niewygodne jak modyfikacje w 'GMFGen' lub 'zastępowanie szablonów'. Szczególnie problem widoczny jest właśnie w przypadku biblioteki GMF która generuje naprawdę złożony kod który należy w dużej mierze zmodyfikować. Zastosowanie technologii Guice pozwala na znaczne rozluźnienie relacji pomiędzy poszczególnymi fragmentami budowanego edytora co znacznie upraszcza proces jego kastomizacji.
Bardzo ciekawy jest także dalszy kierunek rozwoju. Tematem przewodnim jest budowanie złożonych projektów opartych o wiele współpracujących modeli czyli koncepcja budowy indeksu modeli (instancji) w ramach środowiska. Rejestr modeli to jedno z pierwszych zadań jakie musi wykonać każdy projektant tworzący IDE. Ponieważ użytkownicy będą tworzyli dziesiątki lub setki instancji modeli w ramach projektu indeksowanie jest konieczne by wzajemnie się one widziały i możliwe były akcje typu wyszukanie czy refaktoring. Ustandaryzowanie tego typu mechanizmów może być kamieniem milowym w kierunku uniwersalnych mechanizmów refaktoringu (połączenie koncepcji index + compare)
Drugim tematem jest budowa tzw. języka bazowego dla reprezentacji wyrażeń. W każdym środowisku tworzymy lub wykorzystujemy jakiś istniejący język wyrażeń by wiązać poszczególne elementy modelu, reprezentować warunki etc. Czy jest to popularny XPATH, kolejna mutacja OCL czy cokolwiek innego mocno zależy to od wymagań tworzonego środowiska. Uproszczenie tego tematu wydaje się być atrakcyjne ale nie jestem pewien czy jest ono konieczne. Mamy już kilka modeli wyrażeń a pomimo tego każdy i tak tworzy własny by najlepiej odpowiadał potrzebom danego systemu. Nie do końca jestem przekonany czy powstanie kolejnego języka (bazowego?) cokolwiek wniesie do tematu. Przyznam że bardziej wolałbym gdyby połączono i dopracowano istniejące języki tak by powstała jedna składnia OCL’a, pojedyncza wersja XPAND’a etc. Możliwe jednak że źle rozumiem kierunek tego podprojektu. Czas więc poszukać dodatkowych informacji co i jak.
XText bez wątpienia wprowadza do środowiska Eclipse co najmniej tak dużo nowych możliwości jak kilka lat temu zrobił to GMF. Gdy tylko skończę czytać kupioną niedawno książkę o GMF biorę się za naukę. Mam nadzieję że analiza tego projektu pozwoli mi rozwiązać także problemy w moim własnym projekcie (koncepcja zastosowania Guice etc.)
