Codeigniter

Jako fanboy CodeIgniter ‘a ciężko mi było spróbować i przekonać się do czegoś innego. CodeIgniter jako framework dla PHP zapewnił to co było mi potrzebne – modularność, porządek – sporą liczbe gotowych modułów. Polubiłem go głównie za bardzo klarowną dokumentację i prostotę całego rozwiązania. Jednak po dłuższej pracy z tym rozwiązaniem odkryłem też jego braki.

Jego prostota po pewnym czasie zaczyna też być jego wadą. Brak wbudowanego CRUD’a i praktycznie nie istniejące wsparcie dla idei modelu (o czym napisał jeden z moich czytelników) to główne wady CI. W przypadku prostych projektów nie stanowi to problemu, modele tworzymy sami, ale trzeba pisać wszystkie zapytania “ręcznie” – dbać o relację pomiędzy złożonymi tabelami i obiektami.

Tym razem kilka słów o robieniu wersji językowych dla naszych aplikacji. Praktycznie każdy framework oferuje jakieś wbudowane rozwiązanie. Wbudowane rozwiązania wiadomo – raz działają szybciej, raz wolniej.

Tak naprawdę mamy do wyboru kilka opcji – trzymanie wszystkiego w osobnych szablonach dla każdej wersji językowej (widoki), wykorzystanie stałych (define('zapisz', 'save') – i odpowiedni plik dla każdego języka), trzymanie danych w tablicach globalnych (array('zapisz' => 'save') – reszta jw).

Potem w grę wchodzą rozwiązania dedykowane – pliki .ini i parsery (m.in. Smarty) no i co tam sobie wymyślimy – można tłumaczenia trzymać w bazie, potem generować jakieś pseudo konfiguracje i podmieniać. Wszystko opiera się na jednej zasadzie – musimy mieć gdzieś oryginał i tłumaczenia.

Początkowo byłem wielkim przeciwnikiem frameworków PHP – wydawał‚o mi się, że narzut i stopień skomplikowania, który w sobie mają zupełnie nie jest mi do szczęścia potrzebny. Pierwsze zetknięcie z Zend Framework było dla mnie dosyć traumatyczne. Rozmiar całej aplikacji przygniótł mnie na tyle, że dla większości moich zastosowań przewyższał on wielkość kodu podstawowego. Biorąc pod uwagę, że musiałem to wgrywać i aktualizować na wiele serwerów przyprawiał mnie o mdłości…