Wygłaszałem dzisiaj prezentacje na KrakSpot Tech#5. Jeżeli ktoś nie był to niech żałuje. Na otarcie łez moja prezentacja o MongoDb:
Alternatywne podejście do baz danych – MongoDb View more presentations from Wojciech Soczyński.Chciałbym też pogratulować wszystkim pozostałym prelegentom ciekawych prezentacji oraz podziękować Zyxowi i Adamowi za inspirującą rozmowę 
. Dziękuję też organizatorom za pizzę i czekam na więcej takich eventów
Każdy serwis wymagający dużej ilości grafiki na stronie jest zmorą “hostodawcy”. Źle zoptymalizowane grafiki pożerają transfer w zastraszającym tempie. Dobrym przykładem będzie tutaj trójwymiarowy dzbanek z wpisu Animacje 3D przy użyciu CSS3. W chwili obecnej zajmuje on 25 KB. Niby niewiele, ale co jeśli takich obrazków miałbym na stronie kilkanaście/kilkadziesiąt? Przy założeniu, że strona byłaby popularna, marnowałbym niepotrzebnie transfer.
Na szczęście deweloperzy z Yahoo! wyszli na przeciw naszym potrzebom i stworzyli narzędzie o nazwie Smush.it. Jest to prosta z pozoru aplikacja online, kompresująca wskazane grafiki. W przypadku wspomnianego dzbanka, plik po kompresji waży tylko 20 KB, czyli 20% mniej. Dla większej ilości obrazków na stronie oszczędności mogą ilość w megabajty.
Jak to działa? Do Smush.it uploadujemy obrazki lub wskazujemy ich adresy online. Narzędzie przy pomocy kilku innych działających w tle, usuwa zbędne bajty z obrazka, nie zmieniając przy tym jego wyglądu ani jakości. Po zakończonej operacji otrzymujemy listę zoptymalizowanych grafik wraz z opisem poczynionych oszczędności oraz linkiem do pobrania. Sprawdzone – działa.
Jakiś czas temu natknąłem się na Agile Toolkit – interesujący framework, pozwalający skupić się tylko i wyłącznie na programowaniu. Podłubałem nieco w tym frameworku, zrobiłem kilka prostych stronek “do szuflady” i na chwilę obecną nie mam do niego większych zastrzeżeń. Jakiś czas temu na blogu projektu pojawił się wpis, w którym autor frameworka prosi o pomoc w tłumaczeniu dokumentacji na inne języki. Znalazłem chwilę, zrobiłem forka na githubie i zacząłem powoli tłumaczyć. Póki co teksty przeze mnie napisane są surowym tłumaczeniem, nienadającym się na wysłanie do macierzystego repozytorium. Wymagają one przede wszystkim korekty edytorskiej lub co najmniej świeżego oka, które wyłapie moje potknięcia (również te w tłumaczeniu). Jeśli macie ochotę i odrobinę wolnego czasu, zróbcie forka z mojego (lub głównego) repozytorium, znajdźcie błędy i/lub przetłumaczcie to, co jeszcze nie jest przetłumaczone. Kto wie, może Agile Toolkit wyrośnie na godnego konkurenta ZF lub Symfony?
Mój fork na githubie – https://github.com/wilgucki/atk4-web Repozytorium projektu – https://github.com/atk4/atk4-web
Każdy używający Zend Frameworka wcześniej czy później natknie się na klasę służącą do tworzenia formularzy – Zend Form. Jest to całkiem przydatna klasa i znakomicie się sprawdza. Sprawdza się świetnie do momentu, kiedy nasz webmaster stwierdzi, że jednak ubranie formularza w dl/dt/dd jest już passe i przydało by się np. ubrać go w tagi ul/li. Mnie właśnie dzisiaj przydarzyła się taka sytuacja, a więc ku pamięci wrzucam rozwiązanie:
Kanał ATOM
class Form extends Zend_Form
public function init() {
$email = new Zend_Form_Element_Text('email');
$email->setLabel('Email:');
$email->addValidator(new Zend_Validate_EmailAddress());
$email->setRequired();
$firstName = new Zend_Form_Element_Text('first_name');
$firstName->setLabel('First name:');
$firstName->setRequired();
$lastName = new Zend_Form_Element_Text('last_name');
$lastName->setLabel('Last name');
$lastName->setRequired();
$this->addElements(array($email, $firstName, $lastName));
}
public function loadDefaultDecorators() {
parent::loadDefaultDecorators();
$this->_decorators['HtmlTag']['options']['tag'] = 'ul';
foreach ($this->_elements as $el) {
if ($el instanceof Zend_Form_Element_Text) {
$el->removeDecorator('HtmlTag');
$el->removeDecorator('Label');
$el->addDecorator('Label', array('tag' => null));
$el->addDecorator('HtmlTag', array('tag' => 'li'));
}
if ($el instanceof Zend_Form_Element_Submit) {
$el->removeDecorator('Label');
$el->removeDecorator('DtDdWrapper');
$el->addDecorator('HtmlTag', array('tag' => 'li'));
}
}
}
}
Co jak i dlaczego ?
Pierwsze na co należy zwrócić uwagę to miejsce modyfikacji dekoratorów – robimy to w metodzie loadDefaultDecorators(). Jest ona wywoływana jako ostatnia metoda w konstruktorze klasy Zend_Form i dzięki temu mamy już dostęp do wszystkich koniecznych obiektów i pól.
Kolejna kwestia na która trzeba zwrócić uwagę to rozróżnienie pomiędzy różnymi rodzajami elementów formularza. Różne klasy mają różne dekoratory w standardzie.
Najbardziej zastanawiający fragment tego kodu to:
$el->removeDecorator('HtmlTag');
$el->removeDecorator('Label');
$el->addDecorator('Label', array('tag' => null));
$el->addDecorator('HtmlTag', array('tag' => 'li'));
Po co najpierw usuwać a następnie ponownie dodawać te same dekoratory ? Ano po to by zamienić je miejscami 
. Flow dekoratorów jest taki, że każdy dekorator dodany później dostaje cały kontent wygenerowany przez te, które były dodane wcześniej. Dzięki temu możemy hierarchicznie budować strukturę HTML-a.
Btw.
Powyższy kod jest z takiej niezbyt świeżej wersji frameworka. Także, jeżeli coś się zmieniło to z góry przepraszam i chętnie przyjmę kod na nowszej wersji
Przy okazji różnych dziwnych spraw, Ferenc Kovacs wrzucił fajną prezentację odnośnie historii Unikodu w PHP i problemach z jego implementacją dla PHP 6. Ciekawa rzecz do obejrzenia:
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6