Problem powinna tu rozwiązać odmienna architektura kompilatora. Zamiast przetwarzania liniowego zdecydowałem się wprowadzić coś w rodzaju drzewa. Instrukcje zostaną teraz zapisane jako obiekty, a nie funkcje, sam OPT natomiast będzie w stanie rozpoznać komendy blokowe w stylu {section}...{/section}. Wszystko zawarte między nimi kompilator zapisze jako podwęzły tej instrukcji, która w dodatku będzie mogła sprawdzić, co tam się zawiera i zrobić inne fajne rzeczy. Tak to się w skrócie przedstawia.
Zastanawiam się, jak to wpłynie na szybkość, bowiem na oko cały proces lekko się wydłuży. Najpierw ciąg tekstu należy rozbić na drzewo, a później to drzewo "uruchomić", generując drugi ciąg :). Największym wyzwaniem są wyrażenia regularne. We wstępnym teście ułożyłem coś takiego: #(\{(\/?)(.*?)\}|{\*.+\*\}|(.?))#si. W zamyśle ma ono dzielić szablon na znaczniki OPT oraz zwyczajny tekst, zwracając je w kolejności występowania. Znaczniki, owszem, zwracane są w całości, lecz tekst idzie znak po znaku. Zapytanie generuje także odrobinę za dużo danych i nie idzie tego wyłączyć. Zaraz po otrzymaniu wyniku sporą ich część muszę kasować poleceniem unset(), by w trakcie kompilacji przypadkiem nie dostać "Limit pamięci przekroczony". Jeżeli ktoś byłby w stanie podsunąć mi konkretną wskazówkę, byłbym wdzięczny.
Napisał NuLL w czwartek, 16 czerwca 2005 o 18:40
Również jestem ciekaw rozwiązania - ja się przmierzam do pisania systemu szablonów dla mojego CMF-a - o ile sam kompilator napisać to małe wyzwanie to napisanie czegoś działa porządnie jest naprwde trudne. Pozatym zadziwia mnie jak dzaiła preg_replace_callback :-( wracajac 2x za dużo wpisów.