Autor wpisu: Splatch, dodany: 03.10.2006 20:54, tagi: php, framework
Zend od jakiegoś czasu rozwija z powodzeniem swój framework. Szturmuje on rynek dzięki wsparciu firmy i dobrej dokumentacji. Zastanawia mnie jednak, dlaczego inni zaczęli kopiować to co w ZF jest. Rozumiem konwencję nazewniczą, ok - to może komuś się podobać, rozumiem strukturę katalogów, może ktoś uzna ją za logiczną.. Nie mniej nazewnictwo i struktura prawdę mówiąc nie różni się niczym od tego co było standardem w PEAR.
Co więcej, niektórzy po prostu przepisują spore fragmenty kodu, które są w ZF na swoje. Zapytam po co? Skoro jest coś podobnego w Zendzie to jaki sens jest w powielaniu praktycznie tego samego (Zend::loadClass, ZendRegistry, Zend_Router_Rewrite itp.)? Pomijam fakt, że Zend jest otwarty w tej chwili i na pomysły i na ludzi i zapytam, czy to ma jakiś sens?
Nie. Nie ma najmniejszego sensu ponieważ klony padną. ZF na 90% kiedyś wyjdzie i z powodzeniem wyprze wszystkie klony. Wyjście ZF to w dużej mierze kwestia prestiżu i marketingu a także być albo nie być dla PHP w świecie “rapid application development”, zgodnie z tym co głosi oficjalna strona http://framework.zend.com: Now, the world’s most popular web programming language gets even better with an easy to use framework for developing the next generation of web applications. . Bez tego Ruby oraz inne języki wspierane frameworkami po prostu zepchną PHP w kąt. Jak widać po statystykach PHP odrobiło spore straty rosnące niemal bez przerwy od zeszłego roku. Czy to tylko zasługa ZF? Wydaje mi się, że w dużej mierze tak.
Wnioskuję, że jeśli ktoś już zaczął robić framework wzorowany na zendowym to zna architekturę tego drugiego i nie tylko łatwiej ale i szybciej byłoby stworzyć to w oparciu o ZF. Pragnę nadmienić, że ZF ewoluuje, ostatnie propozycje zmian dotyczą między innymi warstwy MVC (dodatkowe informacje tu i tu).
Autor wpisu: Splatch, dodany: 27.09.2006 23:05, tagi: php
Dzisiejszego dnia skończyłem opisywać implementację techniki Mock Objects przy użyciu PHP Unit. Zapraszam do zapoznania się z tekstem i wyrażania opinii na jego temat.
Autor wpisu: Splatch, dodany: 24.09.2006 00:29, tagi: php
Dzisiaj na wiki opisałem wszystkie znane dyrektywy konfiguracyjne generatora dla Propela 1.2 (wygląda na to, że pokrywają się one w dużej mierze z dyrektywami Propela 2.0). W najbliższym czasie opis konfiguracji projektu.
Autor wpisu: Splatch, dodany: 24.09.2006 00:01, tagi: php
Wiem, że Smarty ma równie wielu przeciwników co zwolenników, ale odcinając się od dyskusji postanowiłem polecić zarówno tym pierwszym jak i drugim artykuł na temat obsługi cache w Smarty.
Autor wpisu: Splatch, dodany: 23.09.2006 00:38, tagi: php
Zachęcony komentarzem do poprzedniego posta postanowiłem zoptymalizować cały builder dla Propela. Zasada działania jest taka sama jak wcześniej - usunięcie zbędnych iteracji. Kod generowany przez moje poprawki nie należy do najszybszych, ale z moich testów wynika jednoznacznie - jest szybszy. Szybki sposób instalacji FasterPHP5ComplexPeerBuilder.php: pobrać plik http://delta.dywicki.pl/propel/FasterPHP5ComplexPeerBuilder.php skopiować do folderu propel/engine/builder/om/php5. w build.properties dla projektu ustawić dyrektywę:
PLAIN TEXT CODE:- propel.builder.peer.class = propel.engine.builder.om.php5.FasterPHP5ComplexPeerBuilder
Wskazuje ona na nazwę klasy której obiekt będzie odpowiedzialny za wygenerowanie kodu dla klasy tabeli (*Peer). Po tym wszystkim odpalamy generator z targetem om poleceniem:
PLAIN TEXT CODE:- propel-gen katlog-projektu om
bądź
PLAIN TEXT CODE:- phing -Dproject=nazwa -Dtarget=om
.
Pamiętaj, zmienić można o wiele więcej!
Autor wpisu: Splatch, dodany: 21.09.2006 20:16, tagi: php
Jak wiadomo szybkość nie jest domeną Propela. Dzisiejszego popołudnia na oficjalnym kanale Propela odbyłem rozmowę z osobą która twierdziła, że można przyśpieszyć propela o 3 razy (a przymajmniej metodę doSelectJoinAll). Nie zdziwcie się - miała ona rację! :)
Problem w doSelectJoinAll polega na tym, że są wykonywane zbędne iteracje mające na celu sprawdzenie czy element zawiera obiekt dołączanej encji. Można je z powodzeniem zastąpić odpowiednią mapą, która zawiera identyfikatory tych encji, które już są dodane do obiektu. Osoba, która to twierdziła miała odpowiedni kod, który zgadnijcie - zadziałał. Aby zamiana była uniwersalna - zmieniłem co trzeba w generatorze. Sama metoda działa dwa i pół raza szybciej! Dla zainteresowanych - plik zmieniony przeze mnie - PHP5ComplexPeerBuilder.php. Sprawdź czy Twoje doSelectJoinAll przyśpieszy. :)
Obecnie czasy, które uzyskuje: 0.045847177505493s - nowy build 0.06196403503418s - stary build Nie mniej wcześniej różnice były znaczne - stary build potrafił zająć do 0.12 s! Wynik prosty - po zmianach (czasy mają znacznie mniejsze wahania) można przyśpieszyć tylko tą jedną metodę o dwa razy. Różnica będzie rosła wraz z ilością kluczy obcych w jednej tabeli. Im ich więcej tym stary build będzie wolniejszy.