Wszystko przebiegało następująco. Pomyślałem, że skoro mam już najświeższą wersję biblioteki, wykorzystam ideę komponentów, aby ułatwić sobie tworzenie formularzy. Jakież było moje zdziwienie, kiedy okazało się, że kompilator zadławił się, gdy nie podałem żadnego parametru, choć w teorii mogłem to zrobić (wszystkie były zadeklarowane jako opcjonalne). Następnie musiałem podłubać w parserze wyrażeń, ponieważ szwankowała obsługa odwróconych apostrof. Nawet teraz nie wiem, co się stało, skoro gdzie indziej i wcześniej identyczny kod działał bez problemów. Na sam koniec wyszedł na jaw problem, który przewidywałem, projektując nowiutki algorytm. Domyślnie bierze on informacje o tym, czy napotkana instrukcja rozpoczyna, czy kończy węzeł, od procesorów poszczególnych komend, np. klasy optSection. Jednak w najnowszej wersji dopuszcza on także używanie klauzul, do których żaden z nich się nie przyznaje, przynajmniej jawnie i tu pojawia się problem. Kompilator musi sam rozpoznać, co dane homo-niewiadomo ma zrobić z aktualnym węzłem. Tu wzorowałem się na XML'u i dałem: {instrukcja} - rozpocznij węzeł; {/instrukcja} - zakończ węzeł, jeśli zgadzają się identyfikatory. Oczywiście o wariancie {instrukcja/}, tj. zrób węzeł pusty, już nie pomyślałem, co zmusza mnie obecnie do deklarowania parametrów komponentu w dość dziwny sposób: {param name="parametr" value="wartosc"}{/param}.
Poprawki spróbuję zaaplikować do SVN'a jutro, niemniej jednak sprawa zastanowiła mnie, bowiem nie jest to już pierwszy raz, gdy wychodzą na jaw takie poważne braki. Dlatego też rozszerzyłem ideę unitTestów na sam kompilator. W tym celu na bazie optApi napisałem ultraminimalistyczny parser mający robić jedynie za środowisko dla działania testowanego elementu. Poszczególne testy odwołują się bezpośrednio do metod klasy optCompiler, by nie tracić czasu na tworzenie plików testowych oraz, co szczególnie ważne, przepuszczanie ich przez ten wielokrokowy proces, który utrudniałby ewentualną diagnozę. Aktualnie zdołałem napisać procedury kontrolne dla parsera wyrażeń, gdzie ujawnił się jeden dość poważny błąd: `test \` test` - w takim ciągu nie jest prawidłowo escape'owany znak \`. Pozostałe dwie niezdane procedury tyczą się już spraw kosmetycznych - przy łączeniu tablicy tokenów z powrotem w wyrażenie między każdy z nich wstawiane są spacje, co czasami nie jest w ogóle potrzebne. Skontrolowałem także parser parametrów i tu więcej błędów, poza omówionym wyżej, nie stwierdziłem. Zastanawiam się teraz, jak kontrolować sam algorytm kompilacji. Drzewo emulowane za pomocą tablic PHP jest diabelnie trudne nawet do prostego debugowego wyświetlenia. Kiedy pisałem ten element, musiałem napisać własną implementację funkcji print_r, gdyż domyślna sobie nie radziła! A tu mamy nie tylko wyświetlanie, ale i porównanie, czy otrzymane wyniki zgadzają się z danymi kontrolnymi! Oj, będzie ciężko...
