Wydawało mi się, że dosyć uważnie śledzę zmiany w CodeIgniter , ale oczywiście umknęła mi aktualizacja CI do wersji 2.0.3. Co nowego? Zmiany są raczej drobne – głównie są to poprawki zabezpieczeń oraz kosmetyczne “czyszczenie kodu”. Pełna lista zmian do obejrzenia tutaj .
Prędzej czy później w każdej aplikacji dochodzimy do momentu kiedy trzeba rozpoznawać użytkowników. Standardowo problem staramy się rozwiązać poprzez stworzenie kilku standardowych elementów jakimi są formularz rejestracji i logowania.
Bardzo modne ostatnio też są logowania przy pomocy innych usługodawców – czyli znana usługa Facebook for Websites (wcześniej znana jako Facebook connect), logowanie przez konta Gmail , LinkedIn , Twitter czy w końcu OpenID , które było pierwsze, ale jakoś się nie przyjęło. Mamy więc do wyboru sporo alternatywnych metod logowania.
…zależy od jego dokumentacji. Mam tutaj na myśli każde wolne oprogramowanie gdzie pracuje się przy źródłach czy API. Z racji na to, że pracujemy już z gotowym oprogramowniem to musimy wiedzieć jak go używać. Jeżeli wszystkie inne metody zawiodły, należy przeczytać instrukcję. Instrukcja wiadomo – zło konieczne, czasami jednak trzeba w niej pogrzebać żeby znaleźć właściwy pstryczek. Dzisiaj więc będzie o instrukcjach, dokumentacjach i ogólnie o wsparciu dla Open Source.
Zasadniczo nie mam nic przeciwko phpMyAdmin . Towarzyszy mi praktycznie od początku przygody z PHP. Wprawdzie przez parę lat przytyło mu się znacznie, ale za to jego ostatnie wersje mają odrobinę Ajaxa dzięki temu nabrał trochę prędkości. Jednak nie o nim będę dzisiaj pisał, tylko o ciekawej alternatywie w postaci CIMyAdmin . Projekt o tyle ciekawy, że oparty o nasz ulubiony 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.
Zwykle jestem bardzo przywiązany do rozwiązań, które znam lubię i… sprawdziłem. Zaskoczyła mnie wiadomość o wypuszczeniu czegoś szybszego (i być może lepszego) niż mój ukochany CodeIgniter . Mowa tutaj o DooPHP , który pojawił się stosunkowo niedawno i zdeklasował mojego faworyta w walce o prędkość.
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…
