Naszym zadaniem jest, oprócz zapisywania błędów aplikacji do logu, automatyczne wysyłanie informacji o problemie na zdefiniowanego maila. Jak to zrobić za pomocą Zend_Log?

Najpierw zainicjujmy zasób log w pliku konfiguracyjnym application.ini:

; log
resources.log.file.writerName = "Stream"
resources.log.file.writerParams.stream = APPLICATION_PATH "/../data/logs/app.log"
resources.log.file.filterName = "Priority"
resources.log.file.filterParams.priority = 5

Informacje o priorytecie 5 (Zend_Log::NOTICE) i ważniejsze zapisywać będziemy do pliku app.log.

Plik Bootstrap.php:

/**
* Log aplikacji
*/
protected function _initRegisterLogger() {
    $this->bootstrap('Log');
    $logger = $this->getResource('Log');

    if ('production' == $this->getEnvironment()) {
        // konfiguracja wiadomości wysyłanej na maila
        $mail = new Zend_Mail('UTF-8');
        $mail->setSubject('Hekima - raport błędu!');
        $mail->addTo('mheki@localhost');

        $writerMail = new Zend_Log_Writer_Mail($mail);

        // logowane tylko błędy z priorytetem WARN i wyższym
        $filter = new Zend_Log_Filter_Priority(Zend_Log::WARN);
        $writerMail->addFilter($filter);

        $logger->addWriter($writerMail);
    }
    // Zapis do rejestru
    Zend_Registry::set('Zend_Log', $logger);
}

Kilka słów wyjaśnienia. Pobieramy zasób Log, w przypadku produkcyjnego środowiska aplikacji, tworzymy obiekt klasy Zend_Mail, który posłuży do wysyłania wiadomości,  a także ustawiamy osobny priorytet wysyłanych informacji (Zend_Log::WARN), następnie informujemy obiekt logujący o tym, żeby logi wysyłał na maila. Na koniec możemy jeszcze zapisać obiekt logujący do rejestru celem późniejszego użycia w aplikacji.

W ostatnim kroku możemy jeszcze rozszerzyć wysyłane informacje, modyfikując w klasie ErrorController domyślną metodę errorAction(). Zamieniamy kod:

if ($log = $this->getLog()) {
    $log->log($this->view->message, $priority, $errors->exception);
    $log->log('Request Parameters', $priority, $errors->request->getParams());
}

na:

if (($log = $this->getLog())) {
    $log->log($this->view->message, $priority, $errors->exception);
    $log->log($errors->exception->getMessage(), $priority);
    $log->log('Parametry wywołania: ' . print_r($errors->request->getParams(), true), $priority);
}

Metoda getLog() wygląda tak:

public function getLog() {
    $bootstrap = $this->getInvokeArg('bootstrap');
    if (!$bootstrap->hasResource('Log')) {
        return false;
    }
    $log = $bootstrap->getResource('Log');
    return $log;
}

A otrzymany mail przykładowo może wyglądać tak:

2013-01-29T09:05:54+01:00 CRIT (2): Błąd aplikacji
2013-01-29T09:05:54+01:00 CRIT (2): SQLSTATE[42S02]: Base table or view not found: 1146 Table 'hekima.test_events' doesn't exist
2013-01-29T09:05:54+01:00 CRIT (2): Parametry wywołania: Array
(
    [module] => test
    [controller] => event
    [action] => index
)

 

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

Zwiń
Czytaj na blogu autora...

Druga wersja Zend Frameworka, rodząca się w bólach, ujrzała światło dzienne kilka miesięcy temu. Zanim mogliśmy cieszyć się stabilną wersją frameworka, otrzymaliśmy do testów kilka wersji beta oraz rc, które stopniowo wprowadzały nas w nowe narzędzie. Wczoraj wydana została wersja (…)

Read the rest of this entry »

Tworząc własne helpery widoku domyślnie dołączane są helpery zawierające się w przestrzeni nazw Zend_View_Helper_ i ulokowane w application/views/helpers. Zdaża się jednak, że w projekcie używamy określonej przestrzeni nazw dla klas. W moich projektach mam zdefiniowaną następująco metodę _initAutoload w bootstrapie, gdzie definiuję przestrzeń nazw jako “SmartGroup_”. Dzieki temu w aplikacji mogę stosować nazwy klas rozpoczynające [...]

W dniu wczorajszym została opublikowana nowa wersja Zend Framework, tym razem oznaczona numerkiem 2.0.4. Główną zmianą jest wprowadzenie dwóch strategii związanych z widokiem: Zend\View\Strategy\JsonStrategy oraz Zend\View\Strategy\FeedStrategy. Ponadto zostało poprawionych ponad 40 zgłoszonych do poprzedniego wydania bugów. Pełna informacja o najnowszym wydaniu Zend Framework oraz lista poprawek jest dostępna tutaj.

Niezaprzeczalną zaletą chmury jest to, że poza kilkoma podstawowymi informacjami, nie musimy przejmować się administrowaniem serwerem, na którym stoi nasza aplikacja. Niestety w praktyce pojawiają pewne drobne przeszkody, skutecznie utrudniające postawienie aplikacji w chmurze, zwłaszcza jeśli aplikacja to coś więcej (…)

Read the rest of this entry »

Zend Framework

Eleganckim sposobem na użycie innego layoutu niż domyślny w jednym z modułów, jest napisanie własnego pluginu, który dołączymy do front kontrolera w klasie bootstrapa modułu. Żeby ten został zaczytany przez naszą aplikację, musimy się upewnić, że zainicjowaliśmy zasób modules np. w pliku application.ini:

resources.modules[] = ""

Dla przykładu załóżmy, że inny layout będzie miał moduł Blog. Tworzymy zatem w katalogu:

/application/modules/blog/

klasę Blog_Bootstrap, w której dołączamy do front kontrolera nasz plugin np. za pomocą metody _initPlugins():

class Blog_Bootstrap extends Zend_Application_Module_Bootstrap {

   protected function _initPlugins(){
        $front = $this->getApplication()
                ->bootstrap('frontcontroller')
                ->getResource('frontcontroller');
        $front->registerPlugin(new Blog_Plugin_Layout());
    }
}

Najpierw pobieramy zasób front kontrolera, następnie rejestrujemy nasz plugin za pomocą metody registerPlugin().

Czas na kod samego pluginu:

class Blog_Plugin_Layout extends Zend_Controller_Plugin_Abstract {

    public function routeShutdown(Zend_Controller_Request_Abstract $request)
    {
        if ('blog' == $request->getModuleName()){
            Zend_Layout::getMvcInstance()->setLayout('blog');    
        }

    }
}

Nasz plugin dziedziczy po klasie Zend_Controller_Plugin_Abstract, a więc możemy użyć metody routeShutdown(), która zostanie uruchomiona zaraz po ustaleniu routingu. Dzięki czemu mamy możliwość sprawdzenia w jakim module aktualnie się znajdujemy. A więc sprawdzamy czy nazwa modułu jest równa ‚blog’, jeśli tak, zmieniamy layout na plik /application/layouts/blog.phtml.

Zend Framework2

A jak wygląda ustalenie specyficznego layoutu dla modułu w Zend Framework 2?

Zmiana layoutu dla modułu w ZF2 jest dużo prostsza:

• instalujemy moduł Evana Coury’ego stąd: https://github.com/EvanDotPro/EdpModuleLayouts
• dodajemy tablicę do pliku konfiguracyjnego modułu:

  array(
      'module_layouts' => array(
          'MyBlog' => 'layout/blog',
      )
  );

I to wszystko

Załóżmy, że w pliku application.ini mamy wpis:

; Paginator
paginator.linesperpage = 10

Jak się do niego dostać w aplikacji?

• w kontrolerze:

$bootstrap = $this->getInvokeArg('bootstrap');
$pConfig = $bootstrap->getOption('paginator');

•  gdziekolwiek:

$front = Zend_Controller_Front::getInstance();
$bootstrap = $front->getParam('bootstrap');
$pConfig = $bootstrap->getOption('paginator');

Polecenie:

Zend_Debug::dump($pConfig);

Daje wynik:

array(1) {
  ["linesperpage"] => string(2) "10"
}