W przypadku gdy mamy wiele różnych metod pobierających kolekcje obiektów z bazy danych i chcemy, żeby były posortowane w podobny sposób — można dodać sortowanie w metodzie doSelect.

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).

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));

W PHP nie ma czegoś takiego jak parametry nazwane z działania, ale jest taka rzecz z …wyglądu. O co chodzi? Mając funkcję:

function foo ($a = 1, $b = 22)
{
    echo $a.' ~ '.$b;
}

Normalnie ją wywołujemy na takie sposoby:

foo() // → '1 ~ 22'
foo (6) // → '6 ~ 22'
foo (3, 4) // → '3 ~ 4'

Jednak możemy sobie funkcję wywołać dodając etykiety parametrom:

foo ($a = 2, $b = 33) // → '2 ~ 33'

Możemy to zrobić również „niepoprawnie”:

foo ($b = 7, $a = 3) // → '7 ~ 3'

Jak widać PHP nie bierze pod uwagę tych nazw parametrów, jedynie kolejność. Nazwy mogą być dowolne, użyte zostaną i tak te z deklaracji funkcji. Powstaje więc pytanie — po co tego w ogóle używać? Otóż — dla przejrzystości kodu, co powinien dobrze zobrazować poniższy przykład:

render_last_posts (10, 'desc', true, null) // → że jakie te posty mają być?
 
render_last_posts ($limit = 10, $sort = 'desc',
    $only_published = true, $by_user = null) // aaa, takie!

UWAGA. Takie przypisania ustawiają wartości zmiennych w danym zakresie, co czasami może doprowadzić do błędów (nadpisanie wcześniej zdefiniowanej zmiennej) lub być sytuacją pożądaną (przypisanie wartości do późniejszego wykorzystania).

Grafika na licencji:

Żeby nie zanudzać tym, co już zostało wiele razy napisane, napiszę szybko, że istnieją 4 sposoby osadzania kodu PHP w pliku, z czego 2 najpopularniejsze wyglądają tak:

<?php $tutaj_kod // sposób standardowy ?>
<? $tutaj_kod // sposób skrócony ?>

O pozostałych dwóch (tag <script language='php'>… i znany z ASP <% … %>) najlepiej od razu zapomnieć, chociażby z tego powodu, że nikt ich nie używa, a pierwszy z nich dodatkowo jest długi, brzydki i nie da się go mieszać z HTML-em.

Więc który sposób jest lepszy?

Jeśli tworzysz oprogramowanie, które ma być możliwie kompatybilne z wszelkimi serwerami i ich konfiguracjami (np. gdy tworzysz framework lub jakąś bibliotekę) właściwie musisz stosować zapis standardowy. Oszczędzi to zapewne wiele frustracji użytkownikom, bo jest to sposób, który zawsze działa. Jeśli jednak opisywany przypadek Cię nie dotyczy to warto stosować zapis skrócony (my go właśnie stosujemy bezproblemowo od dłuższego czasu). Wymaga on co prawda włączenia dyrektywy short_open_tag = On w pliku php.ini, jednak tworzony kod zyskuje sporo na czytelności. Do trybu PHP wskakujemy wtedy umieszczając tylko 2 znaki zamiast 5, natomiast zapis <?php echo 'Cześć' ?> można skrócić się aż o 7 znaków do <?= 'Cześć' ?>. A skoro można coś zapisać krócej, to czemu tego nie zrobić?

Co warto wiedzieć o wychodzeniu z „trybu PHP”

PHP wymaga kończenia  instrukcji średnikiem. Jak jednak widać w poprzednim akapicie, tego średnika nie ma. Jest to dopuszczalne, ponieważ wyjście z „trybu PHP” (?>)  samo wstawia brakujący średnik. Warto to wykorzystać i nie zaciemniać kodu niepotrzebnymi znakami, szczególnie w przypadku gdy „wchodzimy” i „wychodzimy” do PHP w tej samej linii.

Inną sprawą jest fakt, że pliki zawierające w całości kod PHP, nie muszą i właściwie nie powinny mieć zakończenia „trybu PHP” (wtedy jednak nie wolno pominąć średnika w ostatniej instrukcji). Chroni nas to przed specyficzną sytuacją, gdy omyłkowo pozostawione puste linie w plikach ładowanych za pomocą funkcji include lub require spowodują rozpoczęcie wysyłania odpowiedzi (PHP od razu wysyła treść, która nie jest buforowana, ani nie jest kodem PHP), czego typowym następstwem jest komunikat:

 […] headers already sent by […]

Vim posiada dwa bardzo przydatne skróty klawiszowe: ctrl-n oraz ctrl-p. Obydwa służą do dopełniania słów, pierwszy zaczyna szukać za kursorem, drugi przed nim. Domyślnie Vim korzysta ze słów z bieżącego pliku oraz z wszystkich otwartych buforów.

Można jednak tę funkcjonalność rozszerzyć dodając własny słownik. Sam słownik, to zwykły plik tekstowy, w którym słowa są oddzielone białymi znakami. Posiada on jednak dość dziwne ograniczenie — czyta tylko 511 znaków w jednej linii, dlatego nie wolno przesadzać z ich długością.

Słownik może być np. takiej postaci:

dzięciowodoronaftalen
dziewięciodoronaftalen
antypolonazsiderywizacjaimigtenwadsioptaweertyytna
fluorochlorowęglanowodoroazotanocydy
konstantynopolitańczykowianeczka
cześć

Aby skorzystać ze słownika należy dodać 2 linijki (właściwie może być jedna) do ~/.vimrc:

set dictionary+=~/sciezka/do/slownika
set complete+=k

Pierwsza komenda ładuje słownik, druga sprawia, że możemy go przeszukiwać za pomocą wcześniej wspomnianych skrótów (domyślnie trzeba byłoby wciskać ctrl-x-k). Słowników może być wiele.

Słownik możemy sobie utworzyć na bazie plików Vima ze składnią do języków programowania (pod debianopodobnymi w katalogu /usr/share/vim/vim72/syntax/). Należy tutaj jednak pamiętać o ograniczeniu długości linii. Dlatego dla samego PHP udostępniamy gotowy słownik słów kluczowych.

Aby zapisywać w logach wszystkie zapytania jakie się wykonują w naszej bazie danych wystarczy zmienić tylko kilka opcji konfiguracyjnych i zrestartować serwer Postgresa. Tak więc w pliku postgresql.conf (znajdującym się katalogu, w którym trzymane są bazy, zwykle tam gdzie wskzuje zmienna PGDATA, a w „debianopodobnych” w /etc/postgresql/8.x/main/) w sekcji Error Reporting and Logging ustawiamy:

log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'

Gdzie:

• log_destination — tak jest ustawiony domyślnie, więc tylko sprawdzamy czy się nic nie zmieniło.
• logging_collector — włączamy, aby logi trafiające do stderr mogły być zapisane do pliku.
• log_directory — dowolna nazwa katalogu dla logów, znajdującego się katalogu gdzie trzymamy bazę. Jeśli nie ma takiego należy go utworzyć i upewnić się, że postgres ma uprawnienia do zapisu.
• log_filename — nazwa pliku z logami, tutaj ze zdefiniowanym dniem.
• log_statement — grupa zapytań jakie chcemy zapisywać do pliku. Tutaj wybrane wszystkie. Inne opcje: none (wyłączenie zapisu), ddl (zapytania CREATE, ALTER, DROP), mod (tutaj zapewne chodzi o zapytania UPDATE, ale tego nie testowaliśmy).

Jeśli często korzystamy z psql, gdzie wymagana jest autoryzacja, lub też chcemy umożliwić wykonanie jakiegoś skryptu automatycznie (np. z crona) można zapamiętać sobie hasło w specjalnym pliku ~/.pgpass. Składnia jest następująca:

host:port:baza:użytkownik:hasło
host2:port2:baza2:użytkownik2:hasło2
…

Przy czym można użyć *, jeśli nie chcemy jednoznacznie identyfikować któregoś parametru (oprócz hasła oczywiście). Należy pamiętać, że podczas łączenia może być koniecznie podanie hosta i użytkownika, ponieważ ten mechanizm służy jedynie do dopasowywania samych haseł. Na koniec bardziej życiowy przykład dla tych, co tylko kod czytają:

*:*:produkty:admin:tajnehaslo

UPDATE: Tak jak Mistrz Wu w komentarzu sugeruje, nie tyle warto co trzeba zmienić uprawnienia dla tego pliku na 0600. Po dodaniu uprawnień dla grup i innych plik byłby ignorowany.

Xdebug to rozszerzenie do PHP umożliwiające m.in debugowanie i profilowanie aplikacji napisanych właśnie w tym języku. O samej jego instalacji nie ma się co rozpisywać (użytkownikom Arch Linuksa tylko podpowiem, że znajduje się on w AUR).

Po zainstalowaniu, jeśli nasz system tego nie zrobi za nas, trzeba rozszerzenie wstępnie skonfigurować. Na przykładzie wspomnianego Archa zostaniemy dokładnie poinstruowani co trzeba zrobić:

 ==> Please add the following lines to your /etc/php/conf.d/xdebug.ini

 zend_extension=/usr/lib/php/xdebug.so
 xdebug.remote_enable=on
 xdebug.remote_host=<ip address>
 xdebug.remote_port=<port>
 xdebug.remote_handler=dbgp

Jednakże dla nas ważna jest tylko pierwsza linia tych ustawień, ponieważ pozostałe służą do komunikacji z osobnym klientem. Dlatego też można te linie zakomentować, bądź usunąć. Interesuje nas natomiast włączenie profilowania, co można uskutecznić poprzez dopisanie następujących linii do pliku konfiguracyjnego:

xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp

Katalog docelowy jest domyślnie ustawiony na /tmp, więc ta linia tak naprawdę nic nie wnosi, poza tym, żeby było jasno widać jak można ten katalog zmienić.

Następnie restartujemy serwer włączamy stronę www. Po czym w katalogu docelowym powinny znajdować się już raporty o nazwach w rodzaju: cachegrind.out.<PID>.

Raporty takie można otworzyć za pomocą programów KCacheGrind, WinCacheGrind czy MacCallGrind i wyglądają mniej więcej tak:

Na koniec ostateczny wygląd xdebug.ini:

zend_extension=/usr/lib/php/xdebug.so
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp

Najgłupsze, najśmieszniejsze, najbardziej bezsensowne, najciekawsze pełne opisy zmian wgranego kodu w Subversion jakie udało nam się przyuważyć:

• poprawka po zergu. Wstydź się :P
• cos
• refaktoryzacja hahaha
• nie pamiętam co to
• tagusie na dole
• coby hmora taguf smigala jak na waSseLinie
• Debile z PHP nie potrafią nawet gramatyki języka sensownie zrobić.
• coby sie firebug nie denerwowal
• Cichaczem zmieniłem Reinmarowi CSS-a.
• redesign layoutu. O kurwa
• dopieszczanko
• Fix Knorra
• Firefix.
• cosie
• haaa!
• jkopytko
• stylusie dla panelusia administratorka
• dopieszczanie zdzicha
• 3h meki z textilem i nadal nikt nie wie dlaczego niedziala. Ihaha
• Szukarko
• Polska sie pisze z duzej litery
• musk mię boli
• glupia opera
• Zergu, kocham Cię
• +glebogryzarka
• Forms w Syffony to jakiś żart.
• boze , ja nie moge =)
• kod :)
• la la la layout
• Ominięcie buga PHP, który autorzy nazywają ficzerem.
• Tao w kodzie
•  
• Teraz jest dobrze

Jak wiadomo, Vim nie jest IDE. I w sumie dobrze. Jednak jest kilka funkcjonalności, 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 może działać takie wyszukiwanie? Otóż, w naszym przykładzie, po naciśnięciu ctrl+f i wpisaniu interesującej nas nazwy pliku (np. BestPlace) otrzymujemy taki wynik:

Rozwiązanie tego problemu jest przedstawione na stronie http://vim.wikia.com/wiki/Find_files_in_subdirectories. Jednakże, jest ono dość chaotyczne, a efekt końcowy ma pewne wady. Dlatego przedstwiamy sprawę po naszemu.

Cały kod podany poniżej trzeba wstwić 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("")

Następnie funkcja w Pythonie, również pochodząca ze wcześniej wspomnianej strony. 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("")

I na koniec przypisanie sobie funkcji do klawisza:

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à!