Symfony2 - FOSJsRoutingBundle

Za pomocą bundla FOSJsRoutingBundle można korzystać z routingu Symfony w javascriptowym kodzie. Poniżej krótki przykład:

PHP:

 /**
  * @Route("/ks", options={"expose" = true}, name="nfz.raport_wykbadpoz_kolumny_standardowe")
  * @Template("raport/kolumny_standardowe.html.twig")
  *
  * @return array
  */
 public function kolumnyStandardoweAction()
 {
  $ar_kolumny_standardowe = $this->raportWykbadpozManager->getKolumnyStandardowe();
  return compact('ar_kolumny_standardowe');
 }

JavaScript:

$.wczytajKolumnyStandardowe = function(url){
    var kolumny_standardowe = $("#kolumny_standardowe");

    $.post(Routing.generate("nfz.raport_wykbadpoz_kolumny_standardowe"), {}, function(data){
        kolumny_standardowe.html(data);
    });
};

Należy pamiętać o options={"expose" = true} w annotacjach. Więcej informacji na githubie.

Symfony2 i generowanie plików PDF

KnpSnappyBundle

Do generowania plików PDF w Symfony2 wiele osób poleca bundla o nazwie KnpSnappyBundle. Wykorzystuje on jednak wkhtmltopdf (open source'owe konsolowe narzędzie do tworzenia plików PDF na podstawie HTML), które trzeba dodatkowo zainstalować na serwerze produkcyjnym (wraz z wieloma innymi bibliotekami). To według mnie spora wada tego bundla ale jeszcze do przeskoczenia. Większym minusem wkhtmltopdf jest to, że PDF'y na różnych maszynach generują różne pliki PDF. Różnice są niby niewielkie ale przy mojej pracy zupełnie dyskwalifikujące to rozwiązanie.

PdfBundle

PdfBundle autorstwa Piotra Śliwy eliminuje wady wcześniej omówionego bundla. Nie trzeba na serwerze instalować osobnych  systemowych narzędzi i na każdej maszynie wydruk wygląda identycznie. PdfBundle korzysta z biblioteki PHPPfd tego samego autora. PHPPfd tworzy pliki PDF (lub pliki graficzne) na podstawie plików XML co może być to istotną wadą dla niektórych użytkowników. Dla mnie jednak jest to rozwiązanie niemal idealne.

PdfBundle - problem z img

Podczas pracy trafiłem na problem, który zawieszał całego Apache'a przy próbie wygenerowania pliku PDF z dużym plikiem jgp:

Aby pozbyć się problemu wystarczy element dynamic-page zmienić na page - czyli:

[kohana][php] Upgrade z wersji 3.1 do 3.3

Oczywiście jak to przy zmianie wersji frameworka kohana (po dłuższym czasie) jest niezła zabawa z dostosowaniem aplikacji. Zmian jest sporo - poniżej przedstawiam te, które udało mi się zarejestrować szybko przerabiając swoją własną stronkę, która wcześniej stała na wersji 3.1:

Zmiana wielkości liter

Zmienia się wielkość liter katalogów i plików w aplikacji. Na przykład zamiast
application/classes/model/flickr.php
musi być
application/classes/Model/Flickr.php

Brak modułu kohana_cache

Jeśli ktoś używał odpalał ten moduł w bootstrap.php to musi z tego zrezygnować.

Cookie salt

Należy w bootstrap.php (np po i18n) wpisać coś takiego:

Cookie::$salt = 'Your-Salt-Goes-Here';

źródło: http://forum.kohanaframework.org/discussion/8873/cookie-salt-problem/p1

Konfiguracja MySQL

Trzeba zmienić w pliku konfiguracyjnym 'type' z 'mysql' na 'MySQL'.
źródło: http://stackoverflow.com/questions/13043412/error-when-using-auth-with-orm-driver-kohana-3-3-0

Odczyt danych z pliku konfiguracyjnego

Przestaje istnieć - teraz zamiast dawnego:

$config = Kohana::config('nazwa_pliku_konfiguracyjnego');

plik konfiguracyjny odpalamy następująco:

$config = Kohana::$config->load('nazwa_pliku_konfiguracyjnego');

Main request

Wygląda teraz mniej więcej tak u mnie:

$request = Request::factory();
$response = $request->execute()->send_headers(TRUE);

if($response->body()){
    $total = array(
        '{memory_usage}' => number_format((memory_get_peak_usage() - KOHANA_START_MEMORY) / 1024, 2).'KB',
        '{execution_time}' => number_format(microtime(TRUE) - KOHANA_START_TIME, 2).' s.'
    );
    
    echo $response->body(strtr((string) $response, $total));
}

Redirect

Zamiast:

$this->request->redirect(Url::base(FALSE, FALSE).'start');

mamy teraz:

$this->redirect(URL::base(FALSE, FALSE) . 'start');

źródło: http://stackoverflow.com/questions/13088601/kohana-errorexception-fatal-error-call-to-undefined-method-requestredirec

Query builder

Zamiast:

$count = $q_count->select('count("*") AS ilosc')->group_by('tytul','tresc')->execute()->get('ilosc');

mamy teraz:

$count = $q_count->select(array(DB::expr('COUNT(*)'),'ilosc'))->group_by('tytul','tresc')->execute()->get('ilosc');

źródło: http://kohanaframework.org/3.3/guide/database/query/builder

Parametry funkcji action

Zamiast:

public function action_index($kod=''){}

mamy teraz:

public function action_index(){ $kod = $this->request->param('kod'); }

To tyle w mocno telegraficznym skrócie... wg mnie są to dobre zmiany! :)

Więcej informacji: http://kohanaframework.org/3.3/guide/kohana/upgradingguide/kohana/upgrading

[Kohana] Upgrade z 3.0.x na 3.1.x

Upgrade mojej strony (marceen.pl) opartej na Kohanej nie obył się bezboleśnie niestety. Framework cały czas mocno się rozwija a ja - przyznaję się bez bicia - ostatnio nie śledziłem zmian jakie w nim zaszły. :-)
Dziś postanowiłem na własnej skórze zbadać jak mocno się zmieniło to środowisko. I jak się okazuje jest kilka zmian:

Wywołanie widoku

//3.0
$this->request->response = $view;
//3.1
$this->response->body($view);

Wyłapywanie błędu 404

W wersji 3.0 obsługa wyjątku odbywała się w bootstrap.php i wyglądała mniej więcej tak:

try {
    $request->execute();
} catch (Exception $e) { // if its not valid, it gets caught here
    $request->status = 404;
    $request->response = View::factory('errors/404');
}

W wersji 3.1 wygląda to zupełnie inaczej. W bootstrap.php dodajemy jedynie jedną linijkę kodu (koniecznie za Kohana::init()):

set_exception_handler(array('Kruzar_Exception_Handler', 'handle'));

oraz tworzymy klasę Kruzar_Exception_Handler:

class Kruzar_Exception_Handler
{
    public static function handle(Exception $e)
    {
        switch (get_class($e))
        {
            case 'HTTP_Exception_404':
                $response = new Response;
                $response->status(404);
                $view = View::factory('errors/404');
                $view->title = 'ERROR 404 - nie ma takiej strony';
                $view->message  = $view->title;
                $view->message .= $e->getMessage();
                echo $response->body($view)->send_headers()->body();
                return TRUE;
                break;
            default:
                return Kohana_Exception::handler($e);
                break;
        }
    }
}

i umieszczamy w /application/classes/kruzar/exception/handler.php

Odchudzony bootstrap.php

Już na przykładzie powyżej widać optymalizację kodu w bootstrap. Zmiany w tym pliku są większe - część kodu związana z uruchomieniem została przeniesiona do pliku index.php. W bootstrap tylko konfigurujemy śrosowisko - podejście bardzo fajne. :-)

Execution Time

W wersji 3.0 miałem informację (pod zdjęciami) o tym jaki jest czas generowania strony. W związku ze zmianami kawałek kodu który za to odpowiadał nieco trzeba było zmienić i przenieść do pliku index.php:

//zamiast
echo Request::factory()
   ->execute()
   ->send_headers()
   ->body();

//piszemy coś takiego:
$request = Request::factory();
$request->execute();

if ($request->response()->body())
{
   $total = array(
      '{memory_usage}'   => number_format((memory_get_peak_usage() - KOHANA_START_MEMORY) / 1024, 2).'KB',
      '{execution_time}' => number_format(microtime(TRUE) - KOHANA_START_TIME, 2).' s.');
   $request->response()->body(strtr((string) $request->response(), $total));
}

echo $request->response()->send_headers()->body();

To zmiany, przez które dziś przebrnąłem - szerszą informację o zmianach można znaleźć tutaj.

[kohana] cache'owanie

Pisząc poprzedni wpis do bloga zauważyłem, że mój View Large On Black potrzebuje około 2 sekund na wyrenderowanie strony:

W tym czasie aplikacja trzy razy łączy się z api flickr'a aby pobrać dane wyświetlanych zdjęć.
Dane te są stałe więc można tu z powodzeniem wykorzystać cache'owanie.
W kohanej aby dodać dane do cache'a wystarczy:

Kohana::cache($nazwa_zmiennej,$dane);

Odczyt danych wygląda natomiast w ten sposób:

$wynik = Kohana::cache($nazwa_zmiennej,null,$lifetime);

gdzie $lifetime oznacza czas życia zmiennej cache.
Jeśli nie podamy $lifetime:

$wynik = Kohana::cache($nazwa_zmiennej);

to aplikacja będzie uwzględniać dane, które trafiły do cache'a w ciągu ostatnich 60 sekund.
Po umieszczeniu w cache'u danych pobieranych z flickr'a udało się zaoszczędzić ok. 2 sekundy podczas każdego przeładowania i renderowanie strony wynosi ok. 0,02 sekundy.

[kohana] czas renderowania strony

Aby wyświetlić w aplikacji - wykonanej za pomocą frameworka kohana - czas renderowania strony.

W pliku index.php należy dodać linijkę:

define('KOHANA_START_TIME', microtime(TRUE));

W pliku application/bootstrap.php zamiast:

echo Request::instance()
 ->execute()
 ->send_headers()
 ->response;

należy wpisać:

$request = Request::instance($_SERVER['PATH_INFO']);
$request->execute();
if($request->response){
 $total = array(
  '{execution_time}' => number_format(microtime(TRUE) - KOHANA_START_TIME, 5).' s.');

 $request->response = strtr((string) $request->response, $total);
}
echo $request->send_headers()->response;

I na koniec w widoku wystarczy dodać np:

Czas renderowania strony: {execution_time}

[kohana] Usuwanie index.php

Gdy chcesz usunąć z Kohana index.php a zawiodą sposoby przedstawione tutaj i będzie wyświetlał Ci się w dalszym ciągu "Interval Server Error" to spróbuj wpisać

sudo a2enmod rewrite

Zrestartuj Apache'a i spróbuj ponownie - u mnie zadziałało.

W razie problemów zajrzyj jeszcze do httpd.conf i zobacz czy masz coś w tym stylu:

<Directory "/var/www/*">
Order allow,deny
Allow from all
AllowOverride All
</Directory>

W nowszych wersjach Apache'a nie ma już pliku httpd.conf tak więc tę zmianę musimy zrobić bezpośrednio w pliku apache2.conf.