Pliki projektu mogą być różnie rozlokowane w katalogach a ich łączenie odbywa się z wykorzystaniem funkcji include()/require() i ich wariantów *_once()1. Podawanie ścieżek bezwzględnych zupełnie mija się z celem ponieważ inna będzie na komputerze programisty inna na hostingu. Natomiast zmienianie ich przy przegrywaniu jest stratą czasu i narażaniem się na ewentualne problemy (przy zapomnieniu o zmianie czy błędzie w ścieżce).

Rozwiązaniem tego problemu jest dyrektywa konfiguracyjna include_path i używanie ścieżek względnych.

Bieżącą wartość dyrektywy można sprawdzić w następujący sposób:

<?php
print get_include_path(); // u mnie: .:/usr/share/php:/usr/share/pear

Znak kropki w wyniku odnosi się do bieżącego katalogu, natomiast dwukropek to separator ścieżek (można ustawić ich wiele). /usr/share/php i /usr/share/pear to ścieżki, które będą przeszukiwane przy próbie dołączenia plików z użyciem ścieżki względnej.

Jest już przykład odczytania wartość include_path, teraz czas na zmianę wartości i odpowiedź na pytanie: po co to robić?

Do zmiany wartości służy funkcja set_include_path() z pomocą wspomnianej funkcji do odczytu bieżącej wartości oraz stałej PATH_SEPARATOR.

<?php
// wariant 1
set_include_path('/jakas/sciezka/do/katalogu'); 
print get_include_path(); 
// pokaże: /jakas/sciezka/do/katalogu

// wariant 2
set_include_path(get_include_path() . PATH_SEPARATOR . '/jakas/sciezka/do/katalogu');
print get_include_path(); 
// pokaże: .:/usr/share/php:/usr/share/pear:/jakas/sciezka/do/katalogu

Wariant pierwszy pokazuje jak ustawić tylko swoje wartości include_path nadpisując przy tym poprzednie (należy uważać z takim użyciem, ponieważ usunięcie znaku kropki może spowodować wiele komplikacji). Wariant drugi jest dużo mniej inwazyjny i zamiast usuwania poprzednich wartości zwyczajnie dodaje do nich nową oddzielając ją za pomocą stałej (separatorem są znaki dwukropka).

Ostatnią kwestią jest przydatność możliwości zmiany tej dyrektywy. Jedną z sytuacji jest używanie pakietów PEAR, których nie ma globalnie na hostingu i jest jakiś problem z ich zainstalowaniem przez administratora. Rozwiązaniem może być utworzenie w obrębie konta własnego zbioru pakietów PEAR i dodanie ścieżki do tego katalogu do include_path. Późniejsze użycie tych pakietów jest takie samo jak tych dostępnych globalnie.

W najbliższym czasie odbędzie się konferencja PHPCon 2013. A dokładnie to 25-27 października 2013 w Szczyrku. Jest to chyba największa w kraju konferencja związana z językiem PHP a dodatkowo przyjeżdżają też prelegenci z zagranicy. W ubiegłbym tygodniu zakończyło się głosowanie na tegoroczną agendę, z którą można się zapoznać tutaj. Wszyscy zainteresowani konferencją mogą uzyskać więcej informacji na stronie konferencji, a nawet zapisać się – rejestracja uczestników jest jeszcze otwarta.

Jednak oprócz informacji na temat tegorocznego PHPCon chcę też zwrócić uwagę na materiały konferencyjne z poprzednich edycji, ponieważ na prawdę są warte uwagi.

Linki:

1. Strona tegoroczej edycji PHPCon
2. Materiały z PHPCon 2010
3. Materiały z PHPCon 2011
4. Materiały z PHPCon 2012

NetBeans jest moim ulubionym IDE, jeżeli chodzi o język PHP i od kilku dni przyglądam się wersji beta kolejnego wydania – 7.4. Jak zwykle jest po kilka nowości dla różnych kierunków zastosowań IDE – HTML5, PHP, JavaScript, Java, Java EE i innych.

Nowości istotne dla programisty aplikacji internetowych (PHP/JavaScript/HTML5) to między innymi:

• wsparcie dla Zend Framework 2 i Nette Framework 2 z szablonami Latte
• wsparcie dla testów jednostkowych w Atoum
• usprawnienia w refaktoryzacji PHP
• wsparcie dla AngularJS, Knockout i ExtJS
• wsparcie dla PhongeGap
• zapisywanie zmian z Chrome Developer Tools

Z nowości, z których w tym czasie korzystałem, najbardziej przypadł mi do gustu rozwój pluginu obsługi Gita. Pojawiła się na przykład obsługa rebase czy amend i całe menu Git zostało zorganizowane na nowo – bardziej użytecznie. Na uwagę zasługuje również zmiana nazewnictwa opcji na bardziej analogiczne do poleceń „rdzennego”, konsolowego Gita. Teraz obsługa jest bardziej intuicyjna przy przesiadce z konsoli na plugin Git w IDE.

Polecane linki:

• informacje o wydaniu
• NetBeans for PHP blog

Co jakiś czas mam do czynienia z różnymi starszymi projektami napisanymi przez inne osoby. Jedną z bardziej irytujących mnie rzeczy są „magiczne” cyferki. Może jest ktoś (oprócz autora), kto patrząc na poniższy fragment kodu będzie wiedział jakich dokładnie użytkowników zwraca metoda getUzytkownicy()? Niestety ja się do takich osób nie zaliczam.

class Uzytkownik extends AppModel
{
    public function getUzytkownicy() {
        return $this->find('all', array(
            'conditions' => array(
                'Uzytkownik.status' => array(2, 3)
            )
        ));
    }
}

Fragment kodu jest wzorowany na klasie modelu dla CakePHP 1.3, ale pokazany problem jest niezależny od szkieletu programistycznego lub jego braku – to brak czytelności. Nie znająć frameworka z kodu można odczytać, że zwraca on kolekcję obiektów użytkowników o statusach… no właśnie – 2 i 3. Co to znaczy? To najczęściej wie autor i osoby, które musiały już tego poszukać. Pozostali dopiero będą szukali znaczenia tytułowych cyferek. Najczęściej w takich sytuacjach brakuje również komentarza, czy to wewnątrz metody czy PHPDoc dla metody.

Prywatnie rozwiązuję powyższy problem w taki sposób:

class Uzytkownik extends AppModel
{
    const STATUS_NIEPOTWIERDZONY = 1;
    const STATUS_POTWIERDZONY = 2;
    const STATUS_ZABLOKOWANY = 3;
    const STATUS_USUNIETY = 4;
    
    /**
     * Zwraca tablice uzytkownikow potwierdzonych i zablokowanych
     * @return array
     */
    public function getUzytkownicy() {
        return $this->find('all', array(
            'conditions' => array(
                'Uzytkownik.status' => array(
                    self::STATUS_POTWIERDZONY, 
                    self::STATUS_ZABLOKOWANY
                )
            )
        ));
    }
}

Kod z drugiego fragmentu jest o wiele bardziej czytelny i klarowny. Przede wszystkim nie wymaga dodatkowego przeszukiwania kodu i aplikacji, żeby dowiedzieć się co oznaczają poszczególne numery statusów – nazwa stałej jest wystarczająco jasna. Dobrym pomysłem jest również pisanie komentarzy dla metod i późniejsze ich utrzymywanie. Dlaczego utrzymywanie? Ponieważ jeżeli statusy w zapytaniu zostaną zmienione a komentarz nie to będzie wprowadzał w błąd podczas programowania (IDE wyświetli w podpowiedziach metod tylko treść komentarza). W takim wypadku można by stwierdzić, że brak komentarza dla metody jest lepszy niż błędy komentarz – przy braku będziemy się sugerować nazwą lub zajrzymy do kodu, żeby sprawdzić działanie.

Dodatkową kwestią jest też nazwa metody: getUzytkownicy(), można by ją zastąpić getPotwierdzeniIZablokowaniUzytkownicy(). Jednak w tym momencie nazwa metody robi się już trochę długa. Prywatnie metody tego typu staram się nazywać raczej odnosząc się do miejsca lub kontekstu ich wykorzystania. Na przykład getListaUzytkownikowDlaAdm(). Taka nazwa również jest dość długa, ale pozwala dużo lepiej zidentyfikować zastosowanie metody. Dodatkowo w jednej z aplikacji, które rozwijam/utrzymuję obiekt odwzorowujący proces ma 18 statusów wskazujących na różne etapy procesu. Tworząc metodę, której nazwą byłby zlepek np. nazw 6 statusów (których nazwy mogą i często są wieloczłonowe), które powinny mieć obiekty pokazywane na liście byłoby pomyłką.

Podsumowując mam mały apel:

• nazywajmy klasy/metody/stałe/zmienne/etc w sposób bardziej odzwierciedlający to co robią;
• piszmy i utrzymujmy komentarze (najlepiej PHPDoc, żeby można było z nich korzystać poprzez IDE i wygenerować dokumentację);
• nie używajmy „magicznych” cyferek tylko stałych.

Dziękuję