Przeprowadzałem proste badanie i okazuje się, iż konkatenacja nie alokuje więcej pamięci niż stworzenie całego napisu ad hoc, wpływa jednak nieznacznie na czas wykonania takiej operacji (jest to związane z niszczeniem i tworzeniem nowego napisu):

W oby powyższych przypadkach zajętość pamięci jest taka sama, natomiast czas tworzenia napisu różni się o ok 14-17% na korzyść napisu stworzonego w jednym przepisaniu (bez konkatenacji). Nie jest to jednak duża różnica biorąc pod uwagę, iż tworzenie stringa o długości ponad 4 tys znaków zajmuje ok 0.000026 s.

Test był przeprowadzony na dwóch maszynach (laptopie i dzierżawionym serwerze, oba działały pod kontrolą PHP 5.2.6).

Z ciekawostek wartych uwagi jest fakt, iż przypisanie napisu do innej zmiennej nie oznacza alokacji dodatkowej pamięci, jak w tym przypadku:

Pod warunkiem jednak, iż nowo powstały napis nie zostanie zmodyfikowany:

Innymi słowy niejawnie zmienna jest podstawiona przez “pseudo-referencje”  - jeżeli jednak nowo stworzony string się zmieni tworzone jest nowe miejsce w pamięci. Dzieje się tak również w przypadku przekazywania argumentów do funkcji/metody.

Aby zwolnić pamięć zajmowaną przez dany napis wystarczy zrobić jeden z dwóch sposobów:

Problem jest gdy chcemy sprawdzić w warunku ‘if’, czy dane pole posiada błąd. W tym przypadku najczęściej tworzy się możliwość zapisywania wyniku danej funkcji do zmiennej Smarty, w stylu:

W szablonie Smarty wykorzystanie tej wtyczki wygląda następująco:

Niestety jest to mało przyjemne w użyciu… jest jednak inne wyjście - stworzenie prostego modyfikatora w postaci:

Wówczas wykorzystanie jest dużo prostsze i łatwiejsze:

Mimo, iż sam zapis wydaje się dość dziwny - w końcu modyfikatory powstały głównie do “filtrowania” zmiennych, a nie interpretowanie bezpośrednio napisów - to w/w sposób wydaje się idealny do tej sytuacji.

Teoretycznie możemy zrobić tak jak za pierwszym razem - za pomocą klienta FTP wrzucamy cały serwis albo wrzucamy tylko te pliki, które zmieniliśmy. Żadne z tych rozwiązań nie jest wg mnie satysfakcjonujące, ponieważ oba są dość uciążliwe. W pierwszym przypadku kopiowanie całego serwisu jest powolne (przy nawet najdrobniejsze zmianie byśmy musieli wrzucać cały serwis/cały katalog), w drugim natomiast z jednej strony bardzo łatwo pominąć jakiś plik (jest bardzo błednogenne) a z drugiej strony musimy pamiętać (albo ręcznie sprawdzać) jakie pliki zmienialiśmy.

Idealnym rozwiązaniem byłoby “coś”, co pamięta kiedy ostatnio wrzucałem pliki na serwer FTP i przy następnej aktualizacji kopiował tylko te najnowsze. W moim przypadku tym “czymś” jest skrypt biblioteki Ant, biblioteki (zaimplementowanej w języku Java) umożliwiającej tworzenie skryptów w plikach XML realizujących pewne określone zadania (coś w stylu makefile). Więcej informacji na jej temat można przeczytać na stronie producenta Apache Ant.

Przykładowy skrypt wygląda mniej więcej tak (plik o nazwie build.xml):

Jak widać w/w skrypt jest dość czytelny i prosty w związku z czym nie będę się nad nim rozwodzić Idea jest natomiast następująca: pobierz datę ostatniej aktualizacji (linia #6), pobierz pliki (tylko z odpowiednich katalogów) zmieniane od ostatniej aktualizacji (linie #12-19), skopiuj na serwer FTP (linia #10), zapisz aktualną datę jako czas ostatniej aktualizacji (linia #22-24).

Jeszcze lepszym rozwiązaniem byłby kopiowanie plików bezpośrednio z serwera SVN (zakładając, że korzystacie z niego) - niestety nie każdy może sobie na takie rozwiązanie pozwolić, więc trzeba sobie radzić inaczej.

PS. Zalecam korzystanie z platformy Eclipse PDT, która ma wbudowaną obsługę skryptów Ant

Przykład użycia biblioteki Fasic CSV (wraz z nowymi funkcjonalnościami):

Oto lista zmian:

1. [new] Obsługa kodowania, możliwość określania wejściowego i wyjściowego kodowania dla pliku (domyślne UTF-8) W przypadku gdy te kodowania są różne system konwertuję dane do formatu wyjściowego za pomocą iconv.
2. [change] Format mapowania dla obiektu - metoda setMapping klasy Fasic_Csv
   (aktualny format to ‘nazwa_pola’ => ‘numer_kolumny:typ’)
3. [change] Możliwość określania funkcji anonimowej dla mapowania
   (np. ‘name’ => create_function(’$cells’, ‘return strtoupper($cells[2]);’)
4. [new] Możliwość dodania nowych komórek do linii (metoda addMoreCells klasy Fasic_Csv_Line)
5. [new] Proste, ale automatyczne rozpoznawanie separatora dla komórek (między ‘;’ a ‘,’)
6. [change] W metodzie cell (klasa Fasic_Csv_Line) można podać ujemny numer kolumny (wówczas pobierana jest komórka liczona od końca)

W aktualnej wersji nadal nie jest zaimplementowana opcja preLoaded = false, która umożliwiałaby wczytywanie pliku CSV linia po linii (a nie jak jest teraz załadowanie całego pliku do pamięci) - opcja ta zostanie zaprezentowana w wersji 1.0 biblioteki.

Uwaga: mam nadzieje, że oczywiste jest, iż w/w bibliotekę można używać nie tylko w aplikacjach opartych na Zend Framework - równie dobrze można z niej korzystać w jakiejkolwiek innych aplikacjach webowych napisanych w języku PHP.

Biblioteka Fasic_Csv:

• Źródła: http://webprogramming.pl/downloads/Fasic_Csv-0.96.zip
• Wersja: 0.96
• Data edycji: 12 maj 2009
• Instalacja: skopiować do katalogu Fasic, który jest w ścieżce poszukiwań skryptów PHP (w tym samym katalogu, w którym jest katalog Zend),
• Zależności: korzysta z bioblioteki Fasic_Forcetype
• Aktualizacja: w przypadku aktualizacji do nowej wersji wystarczy nadpisać wcześniej istniejące pliki (należy również zapoznać się ze zmianami, wersja 0.96 nie jest całkowicie kompatybilna z wersją 0.9)

1. Zaburzenie standardowej interakcji z użytkownikiem.
2. Niepoprawne działanie przycisku Wstecz/Back w przeglądarce.

Zamiast rozczulać się nad nimi, zastanówmy się jak można sobie z nimi poradzić - tak abyśmy mogli tworzyć aplikacje internetowe podążające za nowościami (korzystające z nowych trendów jakim niewątpliwie jest Ajax), a jednocześnie nie zaburzające standardowych przyzwyczajeń użytkownika. Oto podpowiedzi jak temu zaradzić w przypadku korzystania z jQuery:

1. Zaburzenie standardowej interakcji z użytkownikiem.
   Głównym zarzutem w tej kategorii jest brak wyświetlania informacji użytkownikowi, że coś się dzieje. W przypadku zwykłych żądań przeglądarka “mówiła”, czy dana strona jest ładowana czy też nie. W przypadku zapytań Ajax sami musimy o to zadbać. W dobrym tonie jest też blokowanie linku/przycisku (który aktywuje żądanie Ajax) tak, aby użytkownik nie mógł drugi raz wykonać tej samej akcji (zmniejszy to obciążenie naszego serwera) - z obserwacji moich wynika, że ludzie lubią klikać w nieskończoność na link mając nadzieje, że dzięki temu strona się szybciej załaduje..
   Ważne jest, aby zawsze wyświetlać użytkownikowi odpowiednią informację, iż żądanie jest właśnie obsługiwane (standardowym sposobem jest wyświetlanie kręcącego się kółeczka) - w jQuery można to uczynić na przykład tak:
   1. /*** Metody globalne, dla wszystkich żądań Ajax’owych ***/
   2. // Wyświetl ‘div’ o id ‘loading’ na początku zapytania Ajax
   3. $("#loading").ajaxStart(function(){
   4.    $(this).show();
   5. });
   6. // Schowaj ‘div’ o id ‘loading’ po zakończeniu zapytania Ajax
   7. $("#loading").ajaxStop(function(){
   8.    $(this).hide();
   9. });
   10.  
   11. /*** Metody lokalne, tylko dla aktualnego żądania Ajax’owego ***/
   12. // Wyświetl ‘div’
   13. $(‘#loading’).show();
   14. $.ajax({
   15.    complete: function() {
   16.       // Schowaj ‘div’
   17.       $(‘#loading’).hide();
   18.    }
   19. });
2. Niepoprawne działanie przycisku Wstecz/Back w przeglądarce.
   W tym przypadku wystarczy zainstalować jedną z wtyczek do jQuery, która eliminuje ten problem. Wśród bibliotek, które mogą być w tym pomocne znajdują się między innymi: jQuery History lub jQuery History/Remote. W przypadku biblioteki jQuery History wykorzystanie jej jest bardzo proste (bazując na przykładzie na stronie głównej projektu):
   1. // Funkcja pobierająca treść na podstawie hasha, wykonywana:
   2. // 1. po wykonaniu $.historyInit();
   3. // 2. po wykonaniu $.historyLoad();
   4. // 3. po naciśnięciu przycisku "Wstecz"
   5. function pageload(hash) {
   6.    // Hash nie zawiera znaku ‘#’
   7.    // Div o id ‘content’ przechowuje treść strony
   8.    if(hash) {
   9.       // Pobierz stronę
   10.       $("#content").load(hash + ".html");
   11.    } else {
   12.       // Brak strony do pobrania
   13.       $("#content").empty();
   14.    }
   15. }
   16.  
   17. $(document).ready(function(){
   18.    // Zainicjuj wtyczkę.
   19.    //  W parametrze przekazujemy funkcję, która realizuje pobieranie treści
   20.    $.historyInit(pageload);
   21.    // Zainicjuj zdarzenia załadowania strony
   22.    $("a[@rel='history']").click(function(){
   23.       // Hash określa która stronę mam pobrać
   24.       var hash = this.href.replace(/^.*#/, ”);
   25.       // Załaduj stronę - wykonuje metodę pageload.
   26.       $.historyLoad(hash);
   27.       return false;
   28.    });
   29. });

   Łącząc powyższe rozwiązania z naszą aplikacją możemy uzyskać bardzo funkcjonalną i użyteczną (ang. usability) aplikację internetową, jednocześnie nie irytując użytkownika ;).

Przypomnę, iż poprzednio zaprezentowałem ogólne możliwości biblioteki Fasic_Csv, które między innymi skupiały się na:

• pobraniu następnej (lub dowolnie wybranej) linii z pliku CSV w postaci napisu oraz tablicy komórek
• pobraniu wybranej komórki, dla której można było określać jej typ (patrz biblioteka Fasic_Forcetype)

Powyższe funkcjonalności są dość oczywiste… jednak omawiana biblioteka potrafi coś więcej…a mianowicie pobranie linii w postaci obiektu. Jak do tego się zabrać?

Jak widać na powyższym przykładzie korzystanie z wersji “obiektowej” pobranej linii pliku CSV jest bardziej przejrzyste i ładniejsze. Dodatkowo umożliwia definiowanie typów dla wybranych pól.

Opcja ta okazuję się bardzo przydatna również w przypadku, gdy chcemy pobrać takie same dane z różnych plików (które są zapisane w różnych formatach, czyli np w jednym id jest na pozycji 2 a w drugim na pozycji 9). Wówczas definiujemy dwie różne mapy i w linii #7 rozpoznajemy, którą z nich wykorzystać. Dalsza część naszego skryptu będzie wyglądała identycznie dla każdego pliku.

Powyższy przykład opierał się na bibliotece Fasic_Csv w wersji 0.9, którą można pobrać tutaj. Jednak już niebawem pojawi się następna wersja (poprawione błędy i kilka nowych funkcjonalności).

1. Niezgodność nazw funkcji, mało spójne API.
2. Brak oficjalnego frameworka.
3. Wydajność aplikacji.

Czy coś się zmieniło? Postanowiłem przeanalizować aktualną sytuację w ramach w/w punktów

1. Niezgodność nazw funkcji (np. strpos, str_replace), mało spójne API (kolejność parametrów w funkcjach operujących na napisach).
   Niestety dopóki autorzy interpretatora będą chcieli zachować zgodność z poprzednimi wersjami PHP dopóty ten problem nie zniknie. Według mnie przyszedł czas na odświeżenie podstawowych funkcji i metod i ujednolicenie wszystkiego, nawet kosztem kompatybilności. W szczególnym przypadku można stworzyć nowe, spójne funkcje/metody nie rezygnując ze starych (oznaczając je jednocześnie jako deprected).
2. Brak oficjalnego frameworka.
   W ciągu kilku ostatnich lat powstało dużo frameworków dla PHP (CakePHP, PRADO, phpMVC itp.) jednak wszystkie były tworzone przez programistów “na własną rękę” - cześć z nich natomiast było przeszczepieniem znanego frameworka w określonej technologii (np. Java) do środowiska PHP (np. phpMVC było inspirowane frameworkiem Struts) - niestety nie zawsze udanym. Całe szczęście firma, która najbardziej jest związana z PHP (czyli Zend) przebudziła się ze śpiączki i stworzyła bardzo ciekawy system Zend Framework (o świetnej dokumentacji i bardzo fajnej budowie). Jest to według mnie bardzo jasne światełko w tunelu, do którego śmiało można podążać.
3. Wydajność aplikacji.
   Bardzo często mówi się o wydajności aplikacji napisanych w PHP, niestety w porównaniu z niektórymi językami wydajność może okazać się trochę mniejsza (głównie ze względu na fakt, iż język Java, Python są kompilowane do kodu pośredniego). Jednak dzięki akceleratorom takim jak “Zend Optimalizer”, “eAccelerator”, czy też “Alternative PHP Cache” wydajność ta drastycznie wzrasta, w związku z czym różnice wydajności również drastycznie maleją. Co ciekawsze ostatni z wymienionych ma być dostępny domyślnie wraz z PHP 6… pytanie tylko kiedy ona będzie oficjalnie wydana.

Jak widać póki co tylko punkt pierwszy nie jest “ruszony”, w związku z czym pozostaje nam albo korzystanie z dostępnych funkcji (korzystając z pomocy Eclipse można się nawet do nich przyzwyczaić ;)) albo opakowanie ich w bardziej przystępny (na przykład obiektowy) sposób.

Nie ulega jednak wątpliwości, iż do walki ruszyły dwa dość ciekawe języki (mam tutaj na myśli oczywiście Python ze swoim Django oraz Ruby wraz z Ruby on Rails) w związku z czym PHP musi coraz bardziej walczyć jeżeli nie chce stracić swoich zwolenników.

PS. Czy pominąłem coś, co powinno się znaleźć na tej liście?

Dumając trochę nad tym wyloniła mi się odpowiedź w postaci 3 poziomów wtajemniczenia:

Poziom 1- użytkowy

Do tej grupy należą osoby, które potrafią korzystać z systemu (opartego na ZF), pod warunkiem, że jest on skonfigurowany, jego struktura jest określona, a jego zadaniem jest głównie tworzyć nowe funkcjonalności. Takie osoby wiedzą mniej więcej jak działa Zend Framework na zewnątrz (nie tyka się jego wnętrzności) oraz znają zasady w nim obowiązujące.

Poziom 2 - programistyczny

Osoby, które oprócz wiedzy z poziomu 1 potrafią również poprawiać mniejsze błędy w istniejącym systemie i łatać dziury. Orientują się jak funkcjonuje system, jaki jest przepływ żądania, gdzie i co się znajduje itp. Znając konkretny problem potrafią również znaleźć do niego ładne rozwiązanie oraz zaimplementować je.

Poziom 3 - projektowy

Do ostatniego poziomu natomiast należą osoby, których dodatkowo cechuje duża wiedza, doświadczenie i umiejętność projektowania, dokonywania zmian koncepcyjnych systemu itp. Osoby te znają bardzo dobrze koncepcje wzorców projektowych, dobrych praktyk programistycznych (w szczególności w systemie ZF). Potrafią zaprojektować i przygotować gotowe środowisko programistyczne oparte na systemie Zend Framework zgodne z oczekiwaniami zleceniodawcy.

Oczywiste jest, iż podział jest dość płynny i w niektórych przypadkach ciężko by było zakwalifikować daną osobę do którejś z w/w poziomów. A Ty do której grupy należysz?

Uwaga: podobny opis poziomów można by zdefiniować prawdopodobnie dla wszystkich systemów, czy też frameworków (nie koniecznie musi być nim ZF).

1. dogodne pobieranie całych linii/komórek
2. sprawdzanie poprawności formatu wybranych komórek oraz ich filtrowanie (wymuszanie typu)
3. pomijanie nagłówków jeżeli jest taka potrzeba

Proste wykorzystanie biblioteki:

W przypadku metody ceil(), wartości drugiego i trzeciego parametru są takie same. Wartości typów wykorzystywane w tej bibliotece opierają się na bibliotece Fasic_Forcetype, o której wspomniałem już wcześniej.

Powyższy przykład przedstawia najprostsze wykorzystanie biblioteki Fasic_Csv, w najbliższym czasie przedstawię inny sposób wykorzystania jej. Póki co zapraszam do analizy kodu ;).

Biblioteka Fasic_Csv:

• Źródła: http://webprogramming.pl/downloads/Fasic_Csv-0.9.zip
• Wersja: 0.9
• Data edycji: 10 luty 2009
• Instalacja: skopiować do katalogu Fasic, który jest w ścieżce poszukiwań skryptów PHP (w tym samym katalogu, w którym jest katalog Zend)
• Zależności: korzysta z bioblioteki Fasic_Forcetype

W tym przypadku chciałem przedstawić konkretny przykład problemu użyteczności. Wyobraźmy sobie sytuacje, w której mamy główne menu w postaci (standardowe menu w panelach administracyjnych):

Projektanci zażyczyli sobie, aby obsługa tych zakładek była realizowana za pomocą Ajax (co zwiększa użyteczność panelu - strona będzie się szybciej ładowała), a programiści “na szybko” zrealizują to w taki oto sposób:

Innym słowy za pomocą JavaScript przechwytują kliknięcie na link i obsługują żądanie za pomocą JavaScript/Ajax. Wszytko ładnie wygląda.. dopóki użytkownik nie będzie chciał takiej zakładki otworzyć w nowym panelu (osobiście tak często robię) - wtedy zaczną się schody.

Strasznie mnie irytują strony/serwisy, które ograniczają moje standardowe (i optymalne dla mnie) zachowanie. Tym bardziej, że problem ten łatwo rozwiązać.

Przykładowe rozwiązanie problemu (sprawy techniczne, kod JavaScript).
Dla kodu HTML w postaci:

Wystarczy dodać następujący kod JavaScript, aby po kliknięciu strona załadowała się za pomocą Ajax, ale jednocześnie działała opcja “Otwórz w nowym oknie/panelu” .

Dodatkowo musimy zapewnić po stronie serwera, aby obie opcje zostały odpowiednie obsłużone. Jak widać oba żądania są wysyłane pod ten sam adres URL z tym, że w przypadku żądania Ajax oczekujemy innego wyniku  - wówczas interesuje nas tylko sama zawartość strony (bez menu, nagłówków, stopek, itp).

Typ żądania można poznać za pomocą dodatkowego nagłówka jakie wysyła biblioteka jQuery (biblioteka Prototype też takowy wysyła) - wystarczy sprawdzić, czy istnieje nagłówek ‘X_REQUESTED_WITH’ i czy posiada wartość ‘XMLHttpRequest’ (w przypadku Zend Framework mamy dostępna metodę ‘isXmlHttpRequest’ klasy ‘Zend_Controller_Request_Http’, która robi to za nas). Jeżeli żądanie jest wysłane za pomocą Ajax to wygeneruj tylko treść dla wybranej akcji, w przeciwnym przypadku wygeneruj cała stronę (opakowaną w odpowiedni układ).

Jak widać obsługa nie sprawia większych problemów, a zyskuje się na użyteczności.