Comments for Strzałek's devblog http://strzalek.net/blog Just another devblog Thu, 20 Nov 2008 07:48:14 +0000 http://wordpress.org/?v=2.5.1 Comment on Hello world! by empathon http://strzalek.net/blog/1/hello-world#comment-48 empathon Sun, 16 Nov 2008 22:13:37 +0000 #comment-48 Ano logo zacnie to prawda :) Ano logo zacnie to prawda :)

]]> Comment on Doctrine - ORM dla PHP by @property http://strzalek.net/blog/4/doctrine-orm-dla-php#comment-47 @property Fri, 31 Oct 2008 16:02:07 +0000 http://strzalek.net/blog/?p=4#comment-47 a poza tym: /* @var $product Product */ $product = Doctrine::getTable(”Product”) -> find(1); // Doctrine a poza tym:

/* @var $product Product */
$product = Doctrine::getTable(”Product”) -> find(1); // Doctrine

]]> Comment on Doctrine - ORM dla PHP by @property http://strzalek.net/blog/4/doctrine-orm-dla-php#comment-46 @property Fri, 31 Oct 2008 16:00:50 +0000 http://strzalek.net/blog/?p=4#comment-46 @Przemek: http://64.233.183.104/search?q=cache:VgF7RrxWxQIJ:manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.property.pkg.html+phpdoc+%40property&hl=pl&ct=clnk&cd=1&gl=pl @Przemek:

http://64.233.183.104/search?q=cache:VgF7RrxWxQIJ:manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.property.pkg.html+phpdoc+%40property&hl=pl&ct=clnk&cd=1&gl=pl

]]> Comment on Doctrine - ORM dla PHP by Przemek http://strzalek.net/blog/4/doctrine-orm-dla-php#comment-43 Przemek Sun, 19 Oct 2008 10:13:58 +0000 http://strzalek.net/blog/?p=4#comment-43 Mi przeszkadza inna rzecz. Otóż wygenerowane obiekty przez Propel posiadają jawnie zdefiniowane settery/gettery (czy jak kto woli mutatory/akcesory) do wszystkich kolumn obiektu. W sumie mała rzecz, ale jeżeli używasz porządnego IDE (patrz Eclipse PDT) to posiadanie zdefiniowanych funkcji przyspiesza proces programowania (komu by się chciało pamiętać wszystkie kolumny np. ze 100 obiektów w projekcie). Zawsze lepiej jest eliminować takie błędy na etapie tworzenia kodu niż podczas długi sesji debugowania projektu. $product = Doctrine::getTable("Product") -> find(1); // Doctrine vs $product = ProductPeer::doSelectOne(someCriteria); // Propel W wersji Doctrine, żaden IDE do PHP nie będzie wiedział co zawiera $product, więc żadnego podpowiadania właściwości/metod dla $product, dla wersji Propel, Eclipse wyświetli mi całą zawartość tej klasy. Ludzie! Nie utrudniajcie sobie życia! Mi przeszkadza inna rzecz. Otóż wygenerowane obiekty przez Propel posiadają jawnie zdefiniowane settery/gettery (czy jak kto woli mutatory/akcesory) do wszystkich kolumn obiektu. W sumie mała rzecz, ale jeżeli używasz porządnego IDE (patrz Eclipse PDT) to posiadanie zdefiniowanych funkcji przyspiesza proces programowania (komu by się chciało pamiętać wszystkie kolumny np. ze 100 obiektów w projekcie). Zawsze lepiej jest eliminować takie błędy na etapie tworzenia kodu niż podczas długi sesji debugowania projektu.

$product = Doctrine::getTable(”Product”) -> find(1); // Doctrine
vs
$product = ProductPeer::doSelectOne(someCriteria); // Propel

W wersji Doctrine, żaden IDE do PHP nie będzie wiedział co zawiera $product, więc żadnego podpowiadania właściwości/metod dla $product, dla wersji Propel, Eclipse wyświetli mi całą zawartość tej klasy.

Ludzie! Nie utrudniajcie sobie życia!

]]> Comment on Agavi - Wprowadzenie by LBO http://strzalek.net/blog/5/agavi-wprowadzenie#comment-41 LBO Thu, 26 Jun 2008 08:22:42 +0000 http://strzalek.net/blog/?p=5#comment-41 Cholera zjadło mi kod php. Pisałem dokładnie o tym: http://php.net.pl/manual/pl/control-structures.alternative-syntax.php Cholera zjadło mi kod php.

Pisałem dokładnie o tym: http://php.net.pl/manual/pl/control-structures.alternative-syntax.php

]]> Comment on Agavi - Wprowadzenie by LBO http://strzalek.net/blog/5/agavi-wprowadzenie#comment-40 LBO Thu, 26 Jun 2008 08:20:35 +0000 http://strzalek.net/blog/?p=5#comment-40 Hej strzałku przyjrzałem się jeszcze raz i czy uważasz, że pobieranie danych w widoku to dobry pomysł? Co zrobisz w przypadku błędu w modelu? Wiem, że to tylko taka pokazówka, ale dobrze uczyć czytelników dobrych nawyków od samego poczatku. dodatkowo: php specjalnie do zastosowania takiego jak w widoku udostepnia dodatkową notację bez klamerek. To samo tyczy sie innych konstrukcji np. "if :", "endif" - kod jest czytelniejszy. Hej strzałku przyjrzałem się jeszcze raz i czy uważasz, że pobieranie danych w widoku to dobry pomysł?
Co zrobisz w przypadku błędu w modelu?
Wiem, że to tylko taka pokazówka, ale dobrze uczyć czytelników dobrych nawyków od samego poczatku.

dodatkowo: php specjalnie do zastosowania takiego jak w widoku udostepnia dodatkową notację bez klamerek.

To samo tyczy sie innych konstrukcji np. “if :”, “endif” - kod jest czytelniejszy.

]]> Comment on Agavi - Wprowadzenie by Whisller http://strzalek.net/blog/5/agavi-wprowadzenie#comment-39 Whisller Sat, 14 Jun 2008 12:50:53 +0000 http://strzalek.net/blog/?p=5#comment-39 Bardzo fajny artykuł. Szkoda że już od bardzo dawna nie miałem czasu na programowanie z użyciem tego frameworka. Mam nadzieję że to nie ostatni artykuł na temat Agavi :) Bardzo fajny artykuł. Szkoda że już od bardzo dawna nie miałem czasu na programowanie z użyciem tego frameworka.

Mam nadzieję że to nie ostatni artykuł na temat Agavi :)

]]> Comment on Doctrine - ORM dla PHP by Michał Mech http://strzalek.net/blog/4/doctrine-orm-dla-php#comment-34 Michał Mech Fri, 30 May 2008 14:50:22 +0000 http://strzalek.net/blog/?p=4#comment-34 Strzałek poprosiłeś o przykład więc pokuszę się o jeden. Zarówno Doctrine jak i Propel potrafią łączyć obiekty w sensowne relacje, oczywiście jesli odpowiednio zdefiniujemy pliki schema (czy to .yml czy .xml). Załóżmy, że mamy obiekty User i Product z relacją gdzie użytkownik może mieć wiele produktów. W Doctrine przy poprawnej definicji obiektów możemy pobrać wszystkie produkty użytkownika tak: http://phpfi.com/320776 Doctrine jest tak zaprojektowany, że oferuje nam wszędzie fluent interfaces co jest dodatkowym plusem. A jak to wygląda w Propelu? A tak: http://phpfi.com/320777 Gdzie jest przewaga? Otóż wygenerowana funkcja getProducts() posiada opcjonalny parametr będący obiektem Criteria. Różnica błaha, ale istniejąca w całej filozofii oby ORMów. Dzięki takiemu szczegółowi w Propelu jesteśmy w stanie skorzystać z tak oczywistej funkcjonalności jak pobranie produktów usera ale ... posortowanych. Robimy to przekazując dodatkowy obiekt do funkcji. A Doctrine nie da się tego zrobić. Trzeba zapytać ORM korzystając z obiektu Doctrine_Query i samodzielnie zbudować zapytanie, co generuje sporą ilość kodu i jest niewygodne. Zanika wtedy również sens definiowania relacji między obiektami. Ale żeby nie to że demonizuję. Doctrine posiada wiele ciekawych rzeczy, który nie ma Propel. Wspomniane wcześniej bajery ze zdarzeniami i ich nasłuchiwaniem. Fajna sprawa. Strzałek poprosiłeś o przykład więc pokuszę się o jeden.
Zarówno Doctrine jak i Propel potrafią łączyć obiekty w sensowne relacje, oczywiście jesli odpowiednio zdefiniujemy pliki schema (czy to .yml czy .xml). Załóżmy, że mamy obiekty User i Product z relacją gdzie użytkownik może mieć wiele produktów.
W Doctrine przy poprawnej definicji obiektów możemy pobrać wszystkie produkty użytkownika tak: http://phpfi.com/320776

Doctrine jest tak zaprojektowany, że oferuje nam wszędzie fluent interfaces co jest dodatkowym plusem.

A jak to wygląda w Propelu? A tak: http://phpfi.com/320777

Gdzie jest przewaga? Otóż wygenerowana funkcja getProducts() posiada opcjonalny parametr będący obiektem Criteria. Różnica błaha, ale istniejąca w całej filozofii oby ORMów. Dzięki takiemu szczegółowi w Propelu jesteśmy w stanie skorzystać z tak oczywistej funkcjonalności jak pobranie produktów usera ale … posortowanych. Robimy to przekazując dodatkowy obiekt do funkcji. A Doctrine nie da się tego zrobić. Trzeba zapytać ORM korzystając z obiektu Doctrine_Query i samodzielnie zbudować zapytanie, co generuje sporą ilość kodu i jest niewygodne. Zanika wtedy również sens definiowania relacji między obiektami.

Ale żeby nie to że demonizuję. Doctrine posiada wiele ciekawych rzeczy, który nie ma Propel. Wspomniane wcześniej bajery ze zdarzeniami i ich nasłuchiwaniem. Fajna sprawa.

]]> Comment on Agavi - Wprowadzenie by Strzałek http://strzalek.net/blog/5/agavi-wprowadzenie#comment-30 Strzałek Sat, 17 May 2008 10:13:23 +0000 http://strzalek.net/blog/?p=5#comment-30 Z tym kolorowanie kodu i w ogóle wklejaniem kodu w notce i komentarzach coś jest nie tak. Jak będę miał chwile powalczę z tym. <strong>LBO</strong>: Racja. Nie wiedziałem że tak można, a jest dostępne to już od jakiegoś czasu (<a href="http://trac.agavi.org/ticket/655" rel="nofollow">ticket #655</a>). Zmieniłem w notce. Nadal jednak można odwoływać się "po staremu" czyli używając slotów. Z tym kolorowanie kodu i w ogóle wklejaniem kodu w notce i komentarzach coś jest nie tak. Jak będę miał chwile powalczę z tym.

LBO: Racja. Nie wiedziałem że tak można, a jest dostępne to już od jakiegoś czasu (ticket #655). Zmieniłem w notce. Nadal jednak można odwoływać się “po staremu” czyli używając slotów.

]]> Comment on Agavi - Wprowadzenie by splatch http://strzalek.net/blog/5/agavi-wprowadzenie#comment-29 splatch Sat, 17 May 2008 08:25:47 +0000 http://strzalek.net/blog/?p=5#comment-29 Bardzo się cieszę, że poruszyłeś temat Agavi. Jest to framework który prezentuje nieco inne podejście niż istniejące rozwiązania, w szczególności Zend Framework czy Symfony. Z jednej strony wiele wyniósł z Mojavi, z drugiej developerzy dodali gro możliwości, które sprawiają że praca jest rzeczywiście przyjemnością. Wystarczy wspomnieć konfigurację z użyciem XLink, wsparcie dla SOAP, rozbudowane mapowanie adresów (bije na głowę każde, które znam) i na końcu - najlepsze - Form Population Filter. :) Artykuł bardzo fajny. Tak trzymaj! Pozdrawiam, Łukasz Bardzo się cieszę, że poruszyłeś temat Agavi. Jest to framework który prezentuje nieco inne podejście niż istniejące rozwiązania, w szczególności Zend Framework czy Symfony. Z jednej strony wiele wyniósł z Mojavi, z drugiej developerzy dodali gro możliwości, które sprawiają że praca jest rzeczywiście przyjemnością. Wystarczy wspomnieć konfigurację z użyciem XLink, wsparcie dla SOAP, rozbudowane mapowanie adresów (bije na głowę każde, które znam) i na końcu - najlepsze - Form Population Filter. :)

Artykuł bardzo fajny. Tak trzymaj!

Pozdrawiam,
Łukasz

]]>