This post comes from the first version of this blog.
Please send me an email if anything needs an update. Thanks!

Nowa wersja frameworka symfony - Symfony2 powinna już niedługo ukazać się w pierwszej oficjalnej, stabilnej wersji. W świat poszła wiadomość o planowanym wydaniu na koniec marca, czego niestety nie udało się osiągnąć, aczkolwiek zagraniczni blogerzy przewidują opóźnienie nie dłuższe niż 3 miesiące. Aktualną wersją, dostępną do pobrania ze strony symfony.com jest Preview Release 8 [PR8]. W dzisiejszym wpisie chciałbym omówić jeden z problemów, jakie pojawiają się podczas rozpoczynania pracy właśnie z tą wersją.

Wstęp: pracę z frameworkiem czas rozpocząć!

Długo czekałem na jakąś "sensowną" wersję Symfony2, dlatego w momencie, kiedy pojawiła się wiadomość o rychłym wydaniu wersji stabilnej stwierdziłem, że mogę już zaryzykować i zapoznać się z zawartością paczki Preview Release 8. Wcześniej sporo czytałem na temat idei stojących za frameworkiem i ogólnych koncepcji architektonicznych, jakie były obecne w procesie jego projektowania. Otworzyłem stronę symfony.com, kliknąłem w wielki zielony przycisk "download now", wybrałem interesującą mnie wersję "Symfony Standard 2.0.0 PR8 (.tgz)" i po chwili rozpakowałem zawartość do nowego katalogu.

Przejrzałem pobieżnie wszystkie pliki konfiguracyjne, dostosowałem ustawienia tu i ówdzie, a następnie rozpocząłem lekturę wprowadzenia do poszczególnych elementów frameworka. Przyznam, że jest dosyć dużo zmian w samej idei, dlatego raczej niemożliwe jest bezproblemowe przejście z pierwszej wersji (1.4.x) do drugiej (2.0). Zgodnie z tym, co pisało wielu zagranicznych blogerów, a z tego co pamiętam nawet sam Fabien Potencier, Symfony2 to zupełnie inny produkt, który z poprzednią wersją dzieli jedynie nazwę.

Problem: brakujące klasy.

Nauczony doświadczeniem z symfony skorzystałem z "środowiska deweloperskiego" ["dev environment"] do uruchomienia podstawowej instalacji skryptu. Ściągnięta paczka zawierała skonfigurowane pakiety [bundles] dla kilku bibliotek związanych z symfony oraz prosty projekt, na podstawie którego można było wywnioskować wiele przydatnych informacji na temat przepływu sterowania oraz rozmieszczenia poszczególnych informacji we frameworku.

Uruchomiłem testową instalację wykorzystując URL /app_dev.php i… zostałem potraktowany błędem:

Fatal error: Class 'Symfony\Component\DependencyInjection\Compiler\ResolveDefinitionTemplatesPass' not found in [path]\Symfony\vendor\symfony\src\Symfony\Component\DependencyInjection\Compiler\PassConfig.php on line [line]

Myślę sobie - “spokojnie, damy radę”. Zaglądam więc do błędnego pliku i na pierwszy rzut oka wszystko wydaje się być poprawne - poza tym, że z niewiadomego powodu nie działa kolorowanie składni. Przezornie spojrzałem na pozycję i nazwę pliku w drzewie katalogów, gdzie rzucił mi się w oczy jeden nieznaczny szczegół dotyczący rozszerzenia - plik kończył się nazwą .ph, zamiast .php. Zmieniłem na poprawną, wracam do przeglądarki, [F5] i…

Fatal error: Class 'Symfony\Component\DependencyInjection\Compiler\ResolveReferencesToAliasesPass' not found in [path]\Symfony\vendor\symfony\src\Symfony\Component\DependencyInjection\Compiler\PassConfig.php on line [line]

Poprawiłem błąd i tym razem, ale kolejny był już trochę bardziej zaawansowany:

Fatal error: Uncaught exception 'InvalidArgumentException' with message '[WARNING 1549] failed to load external entity "file:///[path]/Symfony/vendor/symfony/src/Symfony/Component/DependencyInjection/Loader/schema/dic/services/services-1.0.xsd" (in n/a - line 0, column 0) [WARNING 3084] Element '{http://www.w3.org/2001/XMLSchema}import': Failed to locate a schema at location 'file:///[path]/Symfony/vendor/symfony/src/Symfony/Component/DependencyInjection/Loader/schema/dic/services/services-1.0.xsd'. Skipping the import. (in in_memory_buffer - line 8, column 0) [ERROR 1845] Element '{http://symfony.com/schema/dic/services}container': No matching global declaration available for the validation root. (in file:///[path]/Symfony/vendor/symfony/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/../Resources/config/web.xml - line 5, column 0)' in F:\www\Symfony2\Symfony\vendor\symfony\src\Symfony\Component\DependencyInjection\Loader\XmlFileLoader.php:397 Stack trace: #0[path]\Symfony\vend in [path]\Symfony\vendor\symfony\src\Symfony\Component\DependencyInjection\Loader\XmlFileLoader.php on line 397

Wszystko nadal krążyło wokół tematu niepoprawnego rozszerzenia pliku [w błędzie wyżej było to .xs zamiast .xsd], ale po kilku kolejnych komunikatach w tym stylu stwierdziłem, że przecież nie będę przerabiał całego frameworka tylko po to, żeby odpalić sobie proste demo. ;] Poszukałem, poszukałem i znalazłem w końcu rozwiązanie.

Rozwiązanie: .zip > .tar.gz.

Zazwyczaj podczas ściągania wszelkiego rodzaju archiwów preferuję format .tar.gz. Tak też zrobiłem i tym razem i to był niestety mój błąd. Po lekturze kilku wpisów analizujących błąd podobny do mojego ktoś stwierdził wprost, że archiwum .tgz jest nieco "wybrakowane".

Rozwiązanie jest proste - należy ściągnąć archiwum w formacie .zip i rozpakować w miejsce “starej” instalacji. W moim przypadku od razu uruchomił się ładny graficzny interfejs aplikacji testowej. W środowisku “dev” mamy ponadto dostęp do pakietu SymfonyWebConfiguratorBundle, czyli swojego rodzaju skryptu konfiguracyjnego, który nieco ułatwia umieszczanie odpowiednich informacji w odpowiednich miejscach.

Trochę niezbyt ciekawy sposób rozpoczynania pracy z nowym produktem na rynku, ale miejmy nadzieję, że doświadczenie płynące z samodzielnej analizy problemu przełoży się na łatwiejsze opanowanie jego zawiłości w późniejszych etapach pracy. ;]