Kilka razy zdarzyło mi się już, że skrypt nad jakim miałem pracować musiał mieć własną nazwę hosta. W związku z tym, że głównie pracuje na WAMP-ie, ustawienie vhosta dla tego skryptu wiązało się z tym, że traciłem możliwość wejścia na standardową stronę główną. Gdzie są różne przydatne rzeczy typu phpMyAdmin czy phpconfig() etc.

Jednak jest sposób na to żeby wilk był syty i owca cała, mianowicie należy sobie skonfigurować vhosty rozróżniane po nazwie (NameVirtualHost).

Jak to zrobić ?

Należy dopisać do apache-owego configa następujące linie:

NameVirtualHost *:80
       <VirtualHost *:80>
       ServerName moja_aplikacja.local
       DocumentRoot "D:/www/moja_aplikacja/public"
       </VirtualHost>
       <VirtualHost *:80>
       ServerName localhost
       DocumentRoot "D:/www/"
       </VirtualHost>

Należy również dodać w pliku \Windows\System32\drivers\etc\hosts wpisy dla każdego nowego adresu wg wzoru:

127.0.0.1 moja_aplikacja.local

Moim drugim ulubionym (po Proxy) wzorcem projektowym jest strategia. Jako, że w większości jego opisów w internecie jest dość abstrakcyjna, postanowiłem przedstawić żywy przykład.

Pewnie robiąc jakieś PHP-owe aplikacje dla biznesu spotkaliście się z potrzebą tworzenia raportów i wykresów. Zwykle były one stałe i pre definiowane. Pisaliście klasę która miała albo osobną metodę dla każdego raportu albo jedna metodę wejściową typu ‘pobierzRaport($nazwa)’ i tam jeden wielki switch.

Nie trudno wymyślić, że nie jest to zbyt elastyczne rozwiązanie. Objętość klasy bardzo nam rośnie przy każdym dodaniu nowego typu raportu i generalnie kod staje się trudnym do utrzymania.

Jest na to rozwiązanie. Definiujemy sobie interfejs IReport:

interface IReport {
    public function getReportData(array $params);
}

Każdy nowy raport będzie implementował ten interfejs i będzie osobną klasą której plik umieścimy np w katalogu application/reports

Zakładając, że nasza aplikacja będzie pisana w jakimś modnym MVC frameworku, kontroler będzie wyglądał tak:

class IndexController extends Some_Cool_Framework_Controller { 
 
    public function reportAction(){
        if($this->_request->isPost()){
              $oModel = new SomeModel();
              $this->_view->reportData = $oModel->getReport($this->_request->getPost());
        }
   }
}

Natomiast model tak:

class SomeModel {
    //... jakies rozne ciekawe metody ...
    public function getReport(array $data){
        $oReportObject = new $data['report_name'];
        return $oReportObject->getReportData($data['params']);
    }
}

W ten sposób nie będziemy dla każdego nowego raportu dokładać do klasy modelu następnej metody czy kolejnego case’a w switchu. Wystarczy stworzyć dowolną klasę która będzie implementować interfejs IReport i dodać ją do wcześniej wspomnianego katalogu.

Oczywiście powyższy przykład jest przykładem naiwnym i należało by dodać do niego filtrowanie danych z post-a.

W oryginalnym rozwiązaniu, lista raportów wraz z nazwami klas raportowych była przechowywana w bazie danych, gdzie przez panel administracyjny można było nimi wygodnie zarządzać.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Ostatni mój wpis na temat PHP był nieco kontrowersyjny. Zadałem w nim pytanie czy PHP ssie i pokazałem co mi się w tym języku nie podoba. W jednym z komentarzy bigZbig zasugerował, bym napisał co mi się w tym języku podoba. Pomysł bardzo fajny, zwłaszcza, że w PHP będę pisał jeszcze długo (mam jedynie nadzieję, że nie w takiej ilości jak obecnie). Wykonałem rachunek sumienia i znalazłem sporo

Jakiś czas temu dyskutowałem na jednym z blogów na temat separatora dla przestrzeni nazw. Niestety autor bloga z jakiejś przyczyny nie chciał zaakceptować moich argumentów i nie opublikował moich komentarzy. Zainspirowało mnie to do dzisiejszego wpisu. Poniżej zebrałem wszystko to, co nie podoba mi się w PHP. Niekonsekwencja. Funkcje nazywane są raz z podkreśleniem w nazwie, raz bez

W dniu dzisiejszym pracowałem nad generowaniem plików PDF w swojej aplikacji. Wybrałem do tego celu Zend_Pdf dlatego że backend jest oparty na Zend Framework.

Współprace z tą biblioteką mogę ocenić na 4/6. Przyjemnie. Jednak brakuje w niej kilku kluczowych elementów jednym z nich jest możliwość zawijania długiego tekstu. W sposób natywny ZF nie ma zaimplementowanej takiej metody.

Poniżej przedstawiam prostą funkcję, która w szybki i sprawny sposób zawinie (przełamie) przekazany tekst po określonej długości znaków.

/**
* Zawin tekst po określonej długości znaków.
*
* @param Zend_Pdf_Page $page
* @param string $text
* @param int $x
* @param int $y
* @param int $width
* @param string $brake
* @param bool $cut
* @return void
*/
function drawTextWrap($page, $text, $x, $y, $width, $brake = "\n", $cut = true)
{
// przygotuj tekst
$text = wordwrap($text, $width, $brake, $cut);
$token = strtok($text, $brake);

$fontSize = $page->getStyle()->getFontSize();

// rysuje każdą linię tekstu niżej od poprzedniej
// o wysokośc (wielkość) czcionki
while (false !== $token)
{
$y -= $fontSize;

$page->drawText($token, $x, $y);

$token = strtok("\n");
};
}

Jeżeli ktoś pracował z Zend_Pdf to wytłumaczenie jak użyć w/w kawałek kodu jest zbyteczne. Pozdrawiam.

Niedawno w ofercie wydawnictwa helion pojawiła się ciekawa książka - Czyty Kod (ang. "Clean code", autor Robert C. Martin). Książka ta opisuje techniki oraz zasady pisania czystego, czytelnego oraz modyfikowalnego kodu. Kilka zasad z tej książki w mojej opinii jest dosyć kontrowersyjnych, ale książka sama w sobie porusza bardzo ważną kwestię, a przede wszystkim jest ona naprawdę dobra.

Głównymi przesłaniami tej książki to:

• waga nazewnictwa klas, funkcji, zmiennych składowych, zmiennych lokalnych i wszystkich pozostałych bytów (pakietów, przestrzeni nazw itp.)
• wszystkie byty (klasy, funkcje, struktury danych itp.) powinny być maksymalnie proste i krótkie. Powinny przedstawiać jedną rzecz, realizować jedną czynność, której istota jest zawarta w opisowej nazwie (punkt pierwszy)

Od tych dwóch zaleceń wywodzi się szereg innych dotyczących zasad budowania klas, funkcji, zależności między modułami i wiele innych. Nie będę ich tutaj oczywiście przytaczał, zainteresowanych odsyłam do tej pozycji.

Idąc śladami autora tej książki, przebuduję mój kod który już wcześniej zamieściłem w notce "Wielostronicowe formularze". Napisałem testy jednostkowe do tej klasy (pisząc plugin, testów nie napisałem ;]), po każdej wprowadzonej zmianie odpalałem testy aby sprawdzić czy klasa nadal działa tak jak powinna.

Nazewnictwo

Pierwszą rzeczą którą zrobiłem to zmiany nazw niektórych metod oraz składowych: - zmiana get/setPage() na get/setCurrentPageNumber, validatePage na validatePageNumber - zmiana getPages() na getNumberOfForms() - zmiana składowej globalNamespace na useGlobalNamespace, analogicznie zmiana nazwy metod dostępowych

Zawahałem się przy metodzie setForms, okazało się że nazwa tej metody wprowadza w błąd, gdyż nie ustawia ona formularzy, a jedynie nadpisuje formularze dla pierwszych stron (błąd logiczny - jeśli przekazaliśmy mniejszą liczbę formularzy niż było ich wcześniej, to na końcu tablicy zostaną formularze z przed wywołania metody). Zdecydowałem się na napisanie dodatkowej funkcji o nazwie addForms, która dopisuje tablicę formularzy. Metoda setForms, tak jak nazwa wskazuje, nadpisuje wcześniej dodane formularze.

Wprowadziłem również inne drobne zmiany nazw (np. zmiennych lokalnych) i wydają się już one być dobre, teraz czas zająć się metodami.

Metody / funkcje

Najważniejsze jest to aby metoda operowała na jednym poziomie abstrakcji, realizowała jedną czynność i była maksymalnie krótka. Na pierwszy rzut oka większość metod spełnia te warunki, ale jest kilka które należałoby poprawić.

Na pierwszy ogień poszła metoda addForm.

[PHP]
public function addForm(sfForm $form)
  {
    $index = count($this->forms);
    $form->setOption('page', $index+1);
    $this->forms[$index] = $form;
 
    if(!$this->isUseGlobalNamespace() && $key = $this->getFormKeyName($form, true))
    {
      $format = $form->getWidgetSchema()->getNameFormat();
      $format = sprintf($this->getNameFormat(), substr($format, 0, $k = strpos($format, '['))).substr($format, $k);
      $form->getWidgetSchema()->setNameFormat($format);
    }
    else
    {
      $form->getWidgetSchema()->setNameFormat($this->getNameFormat());
    }
  }

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

W jaki sposób realizowana jest komunikacja w trybie rzeczywistym pomiędzy serwerem i klientem? Najczęściej wykorzystywany w tym celu jest AJAX. Żądanie wysyłane jest co określoną ilość sekund/minut i w zależności od jego wyniku, wykonywane są odpowiednie akcje. Rozwiązanie to ma dwie zasadnicze wady. Po pierwsze generowany jest ogromny ruch. Po drugie, informacje o zdarzeniach pojawiają się z