Mając utworzony projekt Symfony (1.4) mamy dostęp do zadań (tasków), którymi możemy wygenerować aplikację i moduł:

./symfony generate:app nazwa_aplikacji
./symfony generate:module nazwa_aplikacji nazwa_modułu

O ile aplikacji zwykle jest jedna albo dwie, to modułów może być w danym projekcie całkiem sporo. Więc, jeżeli nie zadowala Cię domyślny wygląd modułu, warto sobie go dostosować do własnych potrzeb. Opłaca się to zrobić choćby dla jednego zmienionego znaku, gdyż sprawa jest bardzo prosta.

Domyślnie Symfony wykorzystuje szkielet, który dostępny jest w jej źródłach w katalogu: lib/task/generator/skeleton.

Aby zmienić domyślny wygląd modułów, wystarczy skopiować ten katalog do własnego projektu do katalogu data. Czyli w katalogu projektu, w data/skeleton powinniśmy mieć takie katalogi jak:

• app
• module
• project

Teraz pozostaje tylko edytować zawartość katalogu data/skeleton/module (nie zmieniamy w źródłach tylko tokena ##MODULE_NAME##), a po utworzeniu nowego modułu, w standardowy sposób, wszystko będzie wyglądać po naszemu.

Co warto zmienić, czyli co ja zmieniam?

• Usuwam zbędne komentarze na początku pliku actions.class.php.
• Formatuję sobie kod wg lepszego standardu (np. taby zamiast spacji).
• Zmieniam dziedziczenie w akcjach na myActions.
• Przygotowuję sobie akcje i widoki pod kątem projektu. Zwykle jest to jakiś prosty CRUD, w którym wystarczy wykonać kilka razy search & replace.

Zmiana domyślnego wyglądu aplikacji i projektu

Jeśli spojrzymy na zawartość katalogu skeleton to widać, że nie tylko moduł może być dostosowany do naszych potrzeb. Ja jednak w katalogach do aplikacji nie mieszałem, bo zbyt rzadko się je generuje, a wygląd początkowy jest zadowalający. Natomiast katalog do generowania projektu musiałby by edytowany w źródłach Symfony co nie jest zbyt fajne. Ale może trafią się komuś takie projekty, że i ten „ficzer” znajdzie zastosowanie.

Podobne wpisy:

1. Dostosowanie grep-a do SVN i Symfony
2. Logowanie do pliku wszystkich zapytań w PostgreSQL
3. Walidacja jednego pola formularza w symfony

public static function doSelect (Criteria $criteria, PropelPDO $con = null)
{
  if (!$criteria->getOrderByColumns())
  {
     $criteria->addAscendingOrderByColumn (self::YEAR);
     $criteria->addAscendingOrderByColumn (self::MONTH);
     $criteria->addAscendingOrderByColumn (self::DAY);
  }
  return parent::doSelect ($criteria, $con);
}

Warunek if umożliwia nam zdefiniowanie dowolnego innego sortowania wcześniej. W przypadku, gdy jakaś metoda (np. getAll) nie definiowała sortowania za pomocą obiektu Criteria — zostanie użyte domyślne (tutaj: po dacie).

Podobne wpisy:

1. Formularze Symfony: select ograniczony przez wartość innego pola
2. PHP: Sortowanie obiektów po dacie utworzenia
3. Symfony: Paginacja przy własnych/nietypowych warunkach SQL

Opis na przykładzie Propela.

Problem

Jak ograniczyć liczbę opcji w sfWidgetFormChoice na podstawie wartości z innego pola formularza. Mowa o ograniczeniu stałym, zdefiniowanym w klasie formularza.

Rozwiązanie

Będąc w klasie formularza mamy dostęp do wartości odpowiadającego obiektu, tylko gdy dany formularz zostanie zainicjalizowany poprzez podanie obiektu do konstruktora (czyli przykładowo $this->form = new SampleForm ($sample_object)). Wtedy możemy pobrać jakąś informację z obiektu i na jej podstawie stworzyć Criteria ograniczające:

$c = new Criteria();
$c->add (APeer::XYZ, $this->getObject()->getAsd());
$this->widgetSchema['asd'] = new sfWidgetFormPropelChoice (array (
    'model' => 'B', 'criteria' => $c));

Podobne wpisy:

1. Walidacja jednego pola formularza w symfony
2. Symfony+Propel: domyślne sortowanie
3. Symfony: Paginacja przy własnych/nietypowych warunkach SQL

$this->form = new PlaceForm ($place);
$this->form->bind ($request->getParameter ('place'));

if ($this->form->isValid())
{
	$place = $this->form->updateObject();
	$place->save();
}

Co jednak kiedy nie chcemy walidować całego formularza? Np. w przypadku kiedy używając InPlaceEditora zmieniamy jedno pole. Podpowiem, że próba wysłania tylko tego jednego pola i wykorzystaniu tej samej akcji skończy się wyzerowaniem pozostałych pól.

Dokumentacja symfony niestety milczy na ten temat (choć przyznam się, że nie szukałem jakoś strasznie dokładnie), a wiemy chyba wszyscy co jest jej największą bolączką – opisanie tylko kilku funkcjonalności poszczególnych modułów. Jak się chce czegoś więcej, to droga wolna – szukajcie sobie sami w kodzie.

Tak też postąpiłem. I po koszmarnie długim czasie odkryłem, że do walidowania każdego z pól służy metoda o intuicyjnej nazwie… clean(). Przykład walidacji jednego pola:

$form = new PlaceForm($place);
try
{
	$cleaned = $form->getValidator($field_name)->clean($value); #1

	$place->setByName($field_name, $cleaned, BasePeer::TYPE_FIELDNAME); #2
	$place->save();
}
catch (sfValidatorError $e) #3
{
	#Obsługa błędu
}

1. Pobranie odpowiedniego walidatora oraz wywołanie na nim metody clean(), która w przypadku, gdy pole ma poprawną wartość zwraca je. A w przypadku błędu wyrzuca wyjątek sfValidatorError,
2. Zapisanie wyczyszczonej wartości tego pola do obiektu,
3. Kod obsługujący przypadek niewalidującego się pola.

Mam nadzieję, że ten krótki artykuł pozwoli komuś zaoszczędzić trochę czasu.

Wpis opublikowałem także na prywatnym blogu reinmar.jogger.pl.

Podobne wpisy:

1. Formularze Symfony: select ograniczony przez wartość innego pola
2. Symfony+Propel: domyślne sortowanie
3. Symfony: domyślny wygląd modułu

Jak wiadomo, Vim nie jest IDE. I w sumie dobrze. Jednak jest kilka funkcjonalności typowych dla IDE, które by się w nim przydały. Jedną z nich jest łatwe otwieranie plików w projekcie. Jako, że nie ma nic takiego wbudowanego, trzeba sobie poradzić samemu.

Jak mogło by takie wyszukiwanie i otwieranie plików działać? Otóż, w naszym przykładzie, po naciśnięciu ctrl+f i wpisaniu interesującej nas nazwy pliku (np. BasePlace) otrzymujemy taki wynik:

Sposób na uruchomienie tego mechanizmu jest przedstawiony na stronie http://vim.wikia.com/wiki/Find_files_in_subdirectories. Jednakże, jest on dość chaotyczny, a efekt końcowy ma pewne wady. Dlatego przedstawiam sprawę po mojemu.

Cały kod podany poniżej trzeba wstawić do własnego .vimrc. Pierwsza część to funkcja do znajdowania, w niezmienionej postaci:

" Find file in current directory and edit it.
function! Find(name)
  let l:list=system("find . -name '".a:name."' | perl -ne 'print \"$.\\t$_\"'")
  let l:num=strlen(substitute(l:list, "[^\n]", "", "g"))
  if l:num < 1
    echo "'".a:name."' not found"
    return
  endif
  if l:num != 1
    echo l:list
    let l:input=input("Which ? (CR=nothing)\n")
    if strlen(l:input)==0
      return
    endif
    if strlen(substitute(l:input, "[0-9]", "", "g"))>0
      echo "Not a number"
      return
    endif
    if l:input<1 || l:input>l:num
      echo "Out of range"
      return
    endif
    let l:line=matchstr("\n".l:list, "\n".l:input."\t[^\n]*")
  else
    let l:line=l:list
  endif
  let l:line=substitute(l:line, "^[^\t]*\t./", "", "")
  execute ":e ".l:line
endfunction
command! -nargs=1 Find :call Find("<args>")

Następnie wstawiamy funkcję napisaną w Pythonie, również pochodząca ze wcześniej wspomnianej strony. Jest ona odpowiedzialna za sam proces wyszukiwania plików. Jednak tutaj zaszło klika zmian:

• szukanie jest niewrażliwe na wielkość znaków,
• szukanie ignoruje katalogi .svn
• rozpoczynając szukanie, nie trzeba potwierdzić (ale też nie można zmienić) katalogu, w którym się szuka; domyślnie jest to katalog w którym otwarliśmy Vima.

python << EOL
import vim
 
def Finder(*args):
    start_dir = vim.eval('getcwd()')
    find_cmd = (r'find %s -iname "*%s*" ! -name "*.svn*" -type f -printf %%p:1:-\\n' % (start_dir, args[0]))
    vim.command("cgete system('%s')" % find_cmd)
    vim.command('botright copen')
EOL
command! -nargs=1 Find :py Finder("<args>")

I na koniec pozostało przypisanie sobie funkcji do skrótu ctrl-f:

map! <C-f> <Esc> :Find ;
map  <C-f> :Find ;

Po :Find jest spacja, aby nie trzeba było jej dopisywać za każdym razem. Teraz wystarczy wykonać :source ~/.vimrc lub zrestartować Vima, a następnie ctrl+f i voilà!

Podobne wpisy:

1. Uprawnienia plików w repo SVN
2. Krótko: Vim i powolna edycja plików PHP
3. Ignorowanie plików w SVN

Użycie LazyLoadingu w Propelu jest bardzo proste, jednak słabo udokumentowane. Polega ono na dodaniu lazyLoad: true w schemacie bazy danych (dla wybranych kolumn). Przykładowy fragment schematu:

  images:
    _attributes: { phpName: Image }
    id: { type: serial }
    data_large: { type: blob, lazyLoad: true }
    data_small: { type: blob, required: true, lazyLoad: true }
    …

Czym jest LazyLoad?

Dla nieznających tego mechanizmu wyjaśnienie. LazyLoad to technika stosowana w warstwie modelu dla wybranych kolumn tabeli. Atrybuty oznaczone do LazdyLoadingu pobierane są tylko i wyłączenie, gdy nastąpi jawne zapytanie o nie. Przykładowo (bazując na powyższym kawałku schematu), podczas wyszukiwania zdjęć, chcemy dostać miniaturki wyników — jednak bez tego mechanizmu pobrane byłyby również duże wersje zdjęć, które w aktualnym widoku nie są potrzebne, a to może bardzo spowolnić wygenerowanie strony.

Podobne wpisy:

1. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1
2. Symfony+Propel: domyślne sortowanie

Dlatego też, trzeba uważać czy nie wywołuje się tej metody więcej niż jeden raz podczas jednego żądania (np. przy kilkukrotnym iterowaniu po wynikach).

Podobne wpisy:

1. Krótko: Vim i powolna edycja plików PHP
2. Symfony: domyślny wygląd modułu
3. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1

Pobieranie obiektów bez wykorzystywania obiektu klasy Criteria jest dość proste. Jednak standardowy paginator w Symfony ma taką właściwość, że jako parametr przyjmuje obiekt tejże klasy. Stwarza to trochę problemów, gdy odpytujemy bazę w niezbyt typowy sposób, a chcemy podzielić wyniki na strony. Przykład: w wyszukiwarce sprawdzamy czy połączone kolumny pasują do podanej frazy.

Prawdę mówiąc nie wiem jak to zrobić w Propelu 1.2 (tym samym Symfony < 1.2), jednak w wersji 1.3 jest już na to sposób dzięki Criteria::CUSTOM. Przykładowo:

$c = new Criteria();
$c->add (CarPeer::BRAND,
         CarPeer::BRAND."||' '||".CarPeer::MODEL.' ILIKE \'%'.$phrase.'%\'',
         Criteria::CUSTOM);
…
$pager->setCriteria ($c);
</code>

Rzeczą, na którą koniecznie trzeba zwrócić uwagę, jest podanie dowolnej kolumny (pierwszy parametr), mimo że nie będzie ona wykorzystywana. Jako drugi parametr podajemy już dokładnie to, co ciężko było normalnie zbudować wykorzystując propelowe kryteria (może to być fragment czystego SQL występującego po klauzuli WHERE). Ostatni parametr jest narzucony i służy do aktywowania całej „magii”.

Podobne wpisy:

1. Formularze Symfony: select ograniczony przez wartość innego pola
2. Symfony+Propel: domyślne sortowanie
3. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1

Krótkie spostrzeżenie na temat wydajności aplikacji (praktycznie nie wypełnionej danymi) po następujących aktualizacjach:

• Symfony 1.1 → Symfony 1.2
• Propel 1.2 → Propel 1.3
• PHP 5.2.0 → PHP 5.2.6
• PostgreSQL 8.1 → PostgreSQL 8.3

Prosty test został wykonany za pomocą ApacheBenchmarka:
ab -c 5 -n 300 -H 'Connection: close'. Jak widać symulacja bazowała na 300 użytkownikach, przy czym do 5 na raz wchodziło na stronę.

Przed aktualizacją

Próba 1:

Requests per second:    4.34 [#/sec] (mean)
Time per request:       1152.770 [ms] (mean)
Time per request:       230.554 [ms] (mean, across all concurrent requests)

Próba 2:

Requests per second:    4.79 [#/sec] (mean)
Time per request:       1043.581 [ms] (mean)
Time per request:       208.716 [ms] (mean, across all concurrent requests)

Po aktualizacji

Próba 1:

Requests per second:    5.33 [#/sec] (mean)
Time per request:       937.318 [ms] (mean)
Time per request:       187.464 [ms] (mean, across all concurrent requests)

Próba 2:

Requests per second:    5.39 [#/sec] (mean)
Time per request:       927.979 [ms] (mean)
Time per request:       185.596 [ms] (mean, across all concurrent requests)

Oczywiście z uwagi na brak testów pomiędzy poszczególnymi zmianami ciężko jest powiedzieć coś więcej, niż tyle że warto aktualizować, choćby o tego jednego requesta na sekundę ;). Ot, taka ciekawostka.

Podobne wpisy:

1. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1
2. PostgreSQL: obliczanie odstępów czasu
3. Walidacja jednego pola formularza w symfony

Jako, że w MySQL nie dzieje się najlepiej postanowiliśmy zmigrować jeden z naszych projektów na Postgresa. Bazuje on na Symfony 1.1, co oznacza starego Propela 1.2.

Samo przestawienie połączenia nie stwarzało większych problemów, wystarczyło w databases.yml i propel.ini przerobić mysql na pgsql:

all:
  propel:
    class:          sfPropelDatabase
    param:
    persistent:       true
    phptype:          pgsql
…

propel.database            = pgsql
propel.database.createUrl  = pgsql://zdzislaw@localhost/
propel.database.url        = pgsql://zdzislaw@localhost/piwo

Przebudowanie modelu, utworzeniu bazy i jej struktury również wykonało się bez problemu, ale to był koniec tego dobrego.

Brak SERIAL

Niestety, propelowy generator skryptu SQL tworzącego schemat bazy nie uraczył nas typem SERIAL przy identyfikatorach, jednakże w samej aplikacji nie stwarza to problemów, ponieważ sekwencje i bez tego są wykorzystywane. Także trzeba po prostu uważać podczas zabawy w CLI Postgresa, gdy mogą one doprowadzić do anomalii z identyfikatorami.

Dane binarne pobierane „ręcznie”

Drobny problem pojawił się w miejscach, gdzie pobieraliśmy dane binarne (BLOB/BYTEA) własnym zapytaniem, omijając wbudowany we framework Active Record. Dane takie trzeba było dodatkowo „od-eskejpować” funkcją stripcslashes.

AKTUALIZACJA: Po aktualizacji projektu do Symfony 1.2 (chociaż tutaj właściwie chodzi o aktualizację Propela do wersji 1.3) okazało się, że żadne stripcslashes nie będzie potrzebne, ponieważ dane binarne (blob) są pobierane jako… stream. Innymi słowy, przy zapytaniach tworzonych samodzielnie, do akcji musiała wkroczyć funkcja stream_get_contents.

GROUP BY

Najwięcej problemów sprawiło grupowanie, ponieważ PostgreSQL ostro trzyma się standardów i wymusza podanie wszystkich używanych kolumn w klauzuli GROUP BY. MySQL natomiast „po cichu” sam sobie je dołączał. Różnicę w zachowaniu prezentuje poniższy (nie mający większego sensu) przykład:

psql=# select sum(id), id from users;
ERROR:  column "users.id" must appear in the GROUP BY clause
or be used in an aggregate function

mysql>  select sum(id), id from users;
+---------+----+
| sum(id) | id |
+---------+----+
|  45     |  1 |
+---------+----+

CONCAT

Łącznie ciągów znaków odbywa się całkiem inaczej w MySQL i PgSQL. W tym pierwszym wykonuje się to za pomocą funkcji CONCAT(), natomiast w drugim wykorzystuje się operator ||. Także trzeba było wykonać małą robótkę ręczną.

FORMAT

W naszym kodzie używaliśmy MySQL-owego FORMAT(), aby ograniczyć liczbę cyfr po przecinku, którego w Postgresie nie ma. Można by tutaj użyć funkcji ROUND(), obecnej i tu i tu, jednak zdecydowaliśmy się przenieść rozwiązanie tego problemu do warstwy języka programowania.

LIKE

LIKE w Postgresie, w przeciwieństwie do MySQL, rozróżnia wielkość znaków. Jednak naprawa tej przypadłości sprowadza się jedynie od zamiany LIKE na ILIKE.

Coś dziwnego

Na koniec coś, czego do końca nie udało nam się zrozumieć. Zaraz po przestawieniu konfiguracji na pgsql, strona przestała odpowiadać (a dokładniej odpowiadała, gdy połączenie z bazą przekroczyło czas oczekiwania). Niemniej jednak PostgreSQL sam w sobie działał, jak również możliwe było połączenie z „czystego” PHP. Jedynie aplikacja Symfony dziwnie się zachowywała. W logach pojawiało się następujące stwierdzenie:

Dec 4 11:20:22 myhost httpd: [wrapped: Could not connect [Native Error: pg_pconnect() [function.pg-pconnect]: Unable to connect to PostgreSQL server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.] [User Info: host=localhost port=80 dbname='piwo' user='zdzislaw'] [User Info: Array]]

Taka sama sytuacja powtórzyła się na dwóch różnych maszynach (jednak na tym samym systemie operacyjnym). Niezrozumiałe jest to, że w czasie różnych zabaw z konfiguracją wszystko wracało do normy, jednak nie bardzo da się znaleźć konkretną przyczynę. Innymi słowy nie potrafimy zreprodukować tej sytuacji.

Krótkie podsumowanie

Migracja rozwiniętego projektu w Symfony okazała się być stosunkowo mało problematyczna. Kłopotów mogło by być jeszcze mniej, gdyby unikać rozwiązań specyficznych dla danego systemu baz danych. Ale w końcu jak często migruje się z jednej systemu zarządzania bazami danych do innego?

Podobne wpisy:

1. Aktualizacja oprogramowania a wydajność
2. Symfony: Paginacja przy własnych/nietypowych warunkach SQL
3. Logowanie do pliku wszystkich zapytań w PostgreSQL