Wczoraj Derick Rethans udostępnił w końcu Xdebug w wersji 2.1.
W ciągu trzech lat (wersja 2.0 ukazała się w lipcu 2007) poprawione wszelkie błędy i skupiono się nad nowymi rozwiązaniami.
Największą nowością jest pełna obsługa PHP 5.3 oraz wsparcia wyłącznie dla PHP od wersji 5.1.
Xdebug w świecie PHP służy najczęściej do debugowania naszych aplikacji. Ale również posiada możliwość profilowania, jak i przeprowadzenia testu pokrycia kodu. D. Rethans dodał bardzo sporo nowości do Xdebuga, oto one:
Jak widać przez te kilka lat zrobione kawał dobrej roboty przy projekcie Xdebug.
Download: Xdebug
Dzisiaj Derick Rethans poinformował na swoim blogu o wydaniu finalnej wersji Xdebug-a 2.1. Ciekawe nowości:
Poza tym usunięto wsparcie dla starych protokołów debbugowania – gdb i php3 oraz poprawiono wiele drobnych błędów, w tym wywalanie się apache’a pod Vistą / Win7.
23 czerwca 2010 r nastąpiło wydanie nowej wersji Eclipse 3.6 Helios . Owo wydanie jest największym z dotychczasowych wydań: 39 różnych zespołów projektowych, 33 miliony linii kodu, 490 commiterów. Eclipse udostępnia 12 różnych projektów, dla różnych typów programistów. W tym oczywiście dla programistów PHP – czyli Eclipse for PHP Developers . Czemu o tym piszę? Przede wszystkim dlatego, że Eclipse PDT jest moim ulubionym IDE, jest tym, na którym pracuję zawodowo, do którego jestem bardzo przyzwyczajony (dotychczas Eclipse Galileo).
Helios wprowadza wiele nowości, część z nich, z punktu widzenia web developera nie ma większego znaczenia. Jednak warto mieć na uwadze zaangażowanie twórców, różnorodność tworzonych rozwiązań, ilość zaangażowanych developerów.
Ostatnie badania wskazały na rosnący udział systemu spod znaku pingwina w ogólnej liczbie developerów korzystających z tego IDE. Twórcy Eclipse wyszli im naprzeciw wprowadzając szereg usprawnień dedykowanych pod systemy z tej kategorii. Stworzony został Linux Tools Project , który ma na celu ułatwienie pracy przy programowaniu w C/C++. Zintegrowano m.in. GNU Autotools, Valgrind, OProfile, RPM, SystemTap, GCov, GProf, LTTng, etc.
Eclipse Marketplace
Jest to klient zapewniający developerom dostęp do czegoś w rodzaju “app-store” z tą różnicą, że dotyczy wtyczek. Daje możliwość łatwego przeglądania i instalowania nowych plug-in’ów. Będzie dostępnych ponad 100 wtyczek w jednym katalogu, co ma znacznie ułatwić i usprawnić ich wybieranie i dodawanie do programu.
Pojawiło się długo oczekiwane wsparcie dla Git’a (popularnego rozproszonego systemu kontroli wersji). Wprowadzone zostało w projektach EGit oraz JGit. Nowe wydanie EGit 0.8 zawiera nowy widok repozytoriów Git’a, wsparcie dla “fast forward merging” oraz tagowania. JGit 0.8 – które jest wykorzystywane w EGicie dla połączeń z repozytoriami Git pokazało duży skok wydajności aż do 50% podczas pracy z dużymi repozytoriami.
WTP wprowadza wsparcie dla tworzenia, uruchamiania i debugowania aplikacji napisanych pod najnowsze specyfikacje Java EE (Java EE 6) włączając Servlet 3.0, JPA 2.0, JSF 2.0, and EJB 3.1.
Framework w JSDT
Ulepszone wsparcie dla JSDT dla programistów JavaScript. W tym framework debugera JavaScript, który umożliwia integrację debugerów JavaScript, takich jak Rhino i Firebug oraz korzystanie z nich bezpośrednio w IDE. Został utworzony nowy pakiet Eclipse IDE for JavaScript Web Developers , który ma na celu ułatwienie programistom JavaScript odszukania, zainstalowania i korzystania z IDE na bazie Eclipse.
Do napisania tego wpisu zainspirował mnie post u Zyx-a pod tym samym tytułem. Zyx przedstawił w nim świeżą koncepcję php-owego frameworka opartego o paradygmat MVC wraz z przykładami kodu. Uzasadnieniem dlaczego „wynajdywał koło na nowo” było to, że uważał, że istniejące frameworki tak na prawdę nie realizują paradygmatu MVC a tylko jego mutację zwaną też MVP. Ten artykuł nie jest bezpośrednio polemiką z Zyx-em a raczej bardziej próbą zademonstrowania podejścia alternatywnego zarówno do tego jakie prezentuj on jak i popularne frameworki.
Chciałbym więc przedstawić pewien zarys frameworka opartego o wzorzec MVP (a raczej MTV ;>) i zasady programowania funk(cyjnego/funkcjonalnego). Napisałem już jeden podobny framework do opisywanego na którym postawiona jest jedna z stron w moim portfolio i dobrze się sprawuje. Natomiast to co opisuje nie posiada jeszcze implementacji i jest w zasadzie kolejną iteracją mojej poprzedniej próby.
Dla jasności przypomnę jeszcze jakie są różnice między MVC i MVP. Oba wzorce służą do separacji warstwy prezentacji aplikacji (View) od warstwy logiki biznesowej (Model).
W MVC kontroler na podstawie requestu łączy odpowiednie modele z odpowiednimi widokami. Widok pobiera odpowiednie dane z modelu wg swojego uznania i tworzy odpowiedź.
W MVP kontroler wyciąga dane potrzebne do renderowania strony z modeli i przekazuje je do widoku. Jak widać w MVP widok nie jest zależny od modelu, po prostu renderuje dane, natomiast w MVC ma świadomość czym jest model (jaką klasą) i potrzebuje konkretnego interfejsu aby móc z nim się porozumiewać.
Wzorzec MVP powstał w celu zapewnienia lepszej testowalności i większej niezależności widoku od modelu.
Sposób działania mojego frameworka.Plik index:
$oContainerConfig = new CContainerConfigXml('config/object-config.xml'); $oFactory = new CContainerManager($oContainerConfig); $oFlowConfig = new CFlowConfigXml('config/flow-config.xml'); $oExecutor = new CExecutor(); $oPageResolver = new CPageResolver($oFlowConfig); $oFrontController = new CFrontController($oPageResolver, $oExecutor, $oFactory, $oFlowConfig); echo $oFrontController->execute($_REQUEST, $_ENV, $_SERVER);
W pliku index widzimy kilka obiektów:
Kanał ATOM
$oFactory jest kontenerem IoC, który konfiguruje wszystkie obiekty jakie istnieją w aplikacji.$oFlowConfig jest obiektem który zwraca nam flow całej aplikacji.$oExecutor jest obiektem wykonującym flow$oPageResolver jest obiektem który na podstawie adresu zwraca informację jaka strona jest żądana oraz parsuje parametryPrzepływ sterowania wygląda tak:
Teraz pewnie zastanawiacie się czym są wymienione między wierszami Command-y? Są to jakby pojedyncze akcje kontrolera, ale silnie wyabstrachowane. Zwracają array() z zmiennymi do widoku albo informacji o redyrekcji na inny adres. Reagują na konkretne eventy takie jak pojawienie się jakiejś zmiennej z get-a lub posta.
Dzisiaj chciałem podzielić się z Wami na temat kilku przemyśleń dot. type hinting i alternatywnego sposobu implementacji tego ficzera. Po co w ogóle type hinting ? Jak dla mnie type hinting spełnia trzy role:
Dzięki roli dokumentacji wiemy jaki typ argumentu należy przekazać do funkcji by działała ona w sposób przewidziany przez jej autora. Dzięki walidacji wejścia autor funkcji upewnia się, że dostaje właściwe parametry, których użyje aby wyprodukować wynik. Natomiast dzięki lukrowi składniowemu jaki dostarcza typ hinting, zamiast pisać przydługawe if-y takie jak:
function foo($bar, $baz, ...){ if(is_int($bar)){ //... } if(is_string($baz)){ //... } }
piszemy po prostu function bar (int $bar, string $baz){//...} co znacznie skraca zapis.
Generalnie w obecnych wersjach języka, jedyną rzeczą jakiej brakuje jest owy cukier składniowy.
Dokumentowanie istnieje dzięki tagom phpDoc, sprawdzić argumenty możemy dzięki wyżej wspomnianemu if-owi. Czyli tak naprawdę type hinting wiele nie wnosi.
Mogłby jednak wnosić bardzo wiele, o ile umożliwiłby nie tylko sprawdzanie typów ale „grubszą” walidacje np. na wyrażenia regularne, czy obecność pewnych kluczy w tablicy. Szalone ? Nie możliwe ? Oczywiście, że nie! Poniżej przykładowa implementacja w Pythonie który umożliwia takie rzeczy a poniżej wytłumaczenie:
from ctypes import ArgumentError from re import match class param: def __init__(self, type, name): self.__type = type self.__name = name def __call__(self, function): def decorated(*args, **kwargs): if self.__type.__class__.__name__ == 'str': test = match(self.__type, kwargs[self.__name]) if test == None: raise ArgumentError('Argument: >>' + self.__name + '<< must match pattern >>"'+self.__type + '"<<') else: arg_type = kwargs[self.__name].__class__.__name__ proper_type = self.__type.__name__ if arg_type != proper_type: raise ArgumentError('Expected object of type >>'+proper_type + '<< for argument >>' + self.__name + '<<') function(*args,**kwargs) return decorated @param(int, 'bar') @param('ala.','baz') def foo(bar, baz): print bar, baz foo(bar = '1', baz='ala ma')
Co ten kod robi ? Kod ten używa ficzera Pythona zwanego dekoratorami funkcji. Pokrótce mówiąc, jest to cukier składniowy dzięki któremu można w łatwy sposób przekształcać funkcje.
@param(int, 'bar') @param('ala.','baz') def foo(bar, baz): print bar, baz
Zapis jest podobny do phpDoca więc powinniście go rozszyfrować – @param(int,'bar') oznacza, że parametr bar funkcji foo powinien być inte-em, natomiast @param('ala.','baz') oznacza, że parametr baz powinien spełniać wyrażenie regularne ‘ala.’
Działa to w ten sposób, że pisząc @param(parametr1, parametr2 ...) przed deklaracją funkcji jest ona przekazywana do wcześniej zdeklarowanej klasy ‘param’, która w konstruktorze bierze argumenty dekoratora(parametr1, paramtr2) a w funkcji __call__ która jest odpowiednikiem php-oweg __invoke robi coś z nimi oraz naszą funkcją i zwraca przekształconą funkcję. W naszym przypadku przeprowadza walidacje parametrów i jeżeli jej nie pasują to wyrzuca wyjątek a jeżeli jest wszystko ok to wywołuje naszą oryginalną funkcje.
I co o tym wszystkim sądzicie ?
. W końcu spełnia się sen niektórych o wywalaniu zaszłości.