Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: Splatch, dodany: 30.08.2006 23:14, tagi: framework, mojavi4

Od publikacji ostatniej noty parę osób proponowało mi podjęcie prac nad Mojavi 4. Chcę wyjaśnić, dlaczego Mojavi 4 nie będę się zajmował.

1. Nie ma nikogo kto byłby w stanie pomóc mi przy projekcie. Obaj byli developerzy zakończyli swoją przygodę z PHP. Nie ma również żadnej społeczności, która jest w stanie zająć się forum, wyłapywaniem błędów - jednym słowem - to by było to samo co robiłem wcześniej przy własnym frameworku.

2. Są projekty, które być może w tej chwili nie dorównują Mojavi 4, lecz są na tyle dobre, że w przyszłości mogą osiągnąć próg czwórki a nawet go przekroczyć.

3. Podobna sytuacja miała miejsce kiedy Sean Kerr zrezygnował z rozwijania Mojavi 3. Później prace nad czwórką przejął Tyler. Gdybym teraz miał zacząć poprawiać Mojavi 4 wyszłaby piątka, której prawdopodobnie bym nie skończył. Czy ktoś by się zajął pozostawioną wcześniejszą wersją?

4. Nie chcę tworzyć większego projektu w PHP, mocno prawdopodobne, że po miesiącu, dwóch po prostu bym zrezygnował z pisania Mojavi pogarszając i tak już wystarczająco ciężką sytuację. Projekt, na który zwrócę teraz baczniejszą uwagę to Agavi. Jest w nim sporo znajomych rzeczy z trójki. Wersja 0.11 jest dużym krokiem w stosunku do 0.10, w której były same poprawki. W trunku widać, że developerzy nie poprzestali na poprawkach i postanowili dodać funkcjonalności. Do ciekawszych należą: routes (Symfony wymięka), translates, output types (w połączeniu z routes daje świetne możliwości), view renderers.

Autor wpisu: Splatch, dodany: 27.08.2006 23:14, tagi: php, framework, mojavi4

Dzisiejszego dnia chciałem napisać coś o Creole by pokazać, że ten sterownik oferuje ciekawą funkcjonalność, ale nie będzie o tym.

To co zmieniło moje zamiary to rozmowa z Tylerem Tomphinsem, osobą prowadzącą od dłuższego czasu projekt Mojavi.

Kontakt z Tylerem jest ciężki, ponieważ on mieszka po drugiej stronie globu. Nasze rozmowy do tej pory wyglądały inaczej, niestety ta, którą zakończyłem przed chwilą zmienia wszystko.

Dowiedziałem się, że Mojavi 4 zostaje zawieszone. Framework, w którym pokładałem ogromne nadzieje, który miał szanse zmienić nieco oblicze aplikacji pisanych w PHP umiera. Można powiedzieć, że historia się powtórzyła, jest to samo co z trójką (mike_mech wykrakał), która została zawieszona dawno, dawno temu. Ówczesny lider projektu - Sean Kerr zrezygnował z jego prowadzenia na rzecz Tylera..

Od tego czasu wiele się zmieniło. Co najważniejsze, zaczęła powstawać dokumentacja, wszystko szło w dobrą stronę, repozytorium może nie tętniło życiem, ale wszystko szło powoli w dobrym kierunku.

To wszystko się skończyło na utracie danych z serwera Mojavi, który miał miejsce bodajże na początku lipca. Najlepszy framework PHP który powstał do tej pory. Żal, że to go spotyka. Ciekawe są okoliczności rezygnacji Tylera z prowadzenia Mojavi, w ogóle z PHP. Jakiś czas temu postanowił przyjrzeć się Ruby i Ruby on Rails by wzbogacić projekt. Teraz do Mojavi a tym bardziej do samego PHP Tyler nie ma zamiaru wracać, ponieważ jest oczarowany wyżej wymienionym językiem. W sumie nie dziwię się mu i szanuję jego decyzję.

Szkoda, wielka szkoda projektu, danych, społeczności.

Autor wpisu: Jaroslaw Mężyk, dodany: 02.08.2006 20:40, tagi: apache

mod_security to moduł serwera Apache będący systemem wykrywania włamań. mod_security analizuje przychodzące dane (metody GET i POST a także cookies) a także dane odsyłane do klienta. Po wykryciu zdefiniowanych w konfiguracji fraz (np. zapytań sql, kodu html, kodu javascript), mod_security wykonuje jedną ze zdefiniowanych akcji. Może to być np. wysłanie do klienta kodu błędu, przekierowanie [...]

Autor wpisu: Splatch, dodany: 31.07.2006 23:19, tagi: php

Zgodnie z tym, co napisałem na forum php.pl zapraszam do ocen, bądź w temacie bądź tu, w zależności od sympatii. ;)

Autor wpisu: WojciechNaruniec, dodany: 23.07.2006 13:33, tagi: php, framework

Dość często potrzebujemy zrobić coś przed lub po wywołaniu każdej z akcji kontrolerów, czy na przykład po zakończeniu wywoływania wszystkich akcji kontrolerów. Aby uniknąć powtarzania takiego samego kodu w wielu miejscach, możemy użyć plugina do kontrolera frontowego. Klasa plugina rozszerza klasę abstrakcyjną. Nie musimy definiować wszystkich jej metod, możemy zdefiniować jedynie te, których chcemy użyć. Ważne [...]

Autor wpisu: Splatch, dodany: 18.07.2006 00:21, tagi: php

Na początku odpowiedź na post, który napisał Zyx.

Aktualnie każdy, kto chce napisać nowe rozszerzenie do PHP, musi tylko znać język C, znać cel swej pracy oraz przeczytać rozdział 46 dokumentacji PHP zatytułowany “Zend API: Hacking the Core of PHP” i poświęcony właśnie tworzeniu modułów.

Zend API to nie wszystko. Moduły kompilowane nie są wyjściem super-uniwersalnym. Na co drugim serwerze nie ma opcji by dorzucić własne rozszerzenie. Wiele modułów z PECLa leży tam od lat, są one praktycznie nie rozwijane, także ich ilość niewiele może poświadczyć.

Projekt ten nie miał nigdy poprawiać po egoistycznie nastawionych twórcach baz danych oraz ich kreatywnym podejściu do implementacji standardu ANSI SQL, ale na plus należy zaznaczyć, że niektóre braki bibliotek klienckich są emulowane (np. podpinanie).

Nikt nie mówi, że PDO miałoby to poprawiać. Spójrz na JDBC, producenci baz samodzielnie dostarczają sterowników do połączeń i dbają o to by były zgodne z własną bazą oraz kolejnymi standardami w JDBC.

Ale głupotą byłoby negowanie go tylko dlatego, że w kwestiach wielkoskalowych ma braki, a Zend ostatnio stosuje dziwne podejście w kwestii doboru priorytetów i debugowania swego sztandarowego projektu.

Diabeł tkwi w szczegółach. Brak stosownych narzędzi i rozwiniętych rozwiązań technologicznych jest sporym problemem, który znacznie utrudnia tworzenie aplikacji.

XML i SAX SAX jest świetnym standardem. Niestety, ustawianie gromady opcji dla parsera to jakaś porażka. Do tego domyślne zmienianie nazw tagów na wielkie litery.. jak by ktoś z tego korzystał. SAX mógłby być świetnym rozwiązaniem, gdyby istniała klasa domyślnego parsera, która wymuszałaby implementacje tylko 2 metod - startElement i endElement. Niestety, jesteśmy skazani na to co, jest w PEAR, czyli kod pisany pod PHP 4. Poza tym problem z SAXem w PHP jest taki, że jeśli ktoś chce korzystać z przestrzeni nazw w dokumencie, którego używa ma niewielkie szanse na to, że cokolwiek uda mu się ugrać, ponieważ parser nie przekazuje do handlera informacji o tym do jakiej przestrzeni nazw należy tag. Dla przykładu w Javie metoda startElement wygląda w następujący sposób:

void startElement(string uri, string localname, string qname, attributes atts) a w PHP void startElementImpl(resource parser, string localname, array atts) czyli zupełnie tak samo jak by tych przestrzeni nie było. Jedyny sposób to wyciąganie prefiksu w nazwie (bo otrzymujemy np foo:bar) i sprawdzanie względem wcześniej zdefiniowanych poprzez xmlns.

DOM Za implementację DOM Panom z Zenda należą się gratulacje, przede wszystkim dlatego, że w końcu jest to moduł doprowadzony do standardu, zgodnie z zaleceniami W3C. Nie będę już narzekał, że jest to DOM Level 2 a nie 3 co by nie było, że się za wiele czepiam ;). Świetnie, że DOM jest częścią Core PHP. Nie ma problemów z tym, czy DOM jest czy nie.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: Splatch, dodany: 15.07.2006 20:37, tagi: php, php6

Postami w tej kategorii chcę pokazać jak dalekie PHP jest od ideału. Mam nadzieję, że większość z tego co piszę kiedyś zostanie poprawiona, nie mniej póki co, są to grzechy ciężkie, które pokazują słabości PHP.

Zend

Zend jest firmą, która bez wątpienia ma największy wpływ na PHP. To Zend tworzy najważniejszy element PHP jakim jest Zend Engine.

To co mam do zarzucenia Zendowi to nieumiejętność wykorzystania swojej pozycji. Nie potrafi on wykorzystać swojej pozycji by ugrać coś na rzecz PHP. Być może dlatego, że jako firma jest zbyt mały by cokolwiek znaczyć. Od jakiegoś czasu Zend powoli produkuje papkę marketingową, którą wciska, że PHP jest enterprise podczas gdy samemu PHP jest do tego bardzo daleko. To, że został zmieniony silnik obsługujący obiekty, upodobniono składnię do Javy, wydano nową (piątą) wersję PHP nie czyni go enterprise.

Kiedy PHP stanie się językiem Enterprise? Kiedy dostarczy stosownych narzędzi i technologii. Niestety w chwili obecnej nie ma ani jednego ani drugiego. PHP jest wciąż językiem, który ma do tego aspiracje, ale nie ma możliwości (zupełnie tak jak Zend). Mam nadzieję, że z biegiem czasu i not z tej kategorii będę to udowadniał.

Z czym się do tej pory kojarzy PHP? Ze “stronkami” produkowanymi przez gimnazjalistów i licealistów. Nie odbiega to od faktów. Pytanie, dlaczego Zend zmierza w kierunku większych klientów? Odpowiedź jest oczywista, większe pieniądze. Tylko, za przeproszeniem, z czym do ludu?!

API, Technologie

Brak jakiegokolwiek API dla rozszerzeń. Parsery XML to nie tylko SAX, nie tylko DOM. Jeśli ktoś chce zaimplementować cały standard samodzielnie czy też go rozszerzać (choćby w samym PHP!) powinna być taka możliwość, niestety do tej pory jej nie ma i prawdopodobnie nie będzie, ponieważ PHP nie jest porządnie zaprojektowane. Inną sprawą jest to, że nikt się tym nie zajmował i nie zajmuje. Błędne koło się zamyka, nikt nie myśli nad nowymi, porządnymi rozwiązaniami oraz technologiami opartymi o ten język, ponieważ PHP nie jest gotowe na taki krok. Wystarczy spojrzeć na Javę… Dla przykładu podam platformę J2EE. Sun publikuje pełną specyfikację i dostarcza przy okazji własny serwer, który w pełni tą specyfikację obsługuje. Nie przeszkadza to by równocześnie na rynku były obecne inne podmioty takie jak JBoss, BEA Web Logic i podstawa wszystkiego - Apache Foundation z Tomcat`em.

Społeczność i Zend Framework

Jak wiadomo społeczność PHP nie jest mała. Względem innych języków można powiedzieć, że jest ogromna. Nie mniej problemem społeczności jest jej podział i brak konsolidacji. Zend nie sprzyja tworzeniu społeczności wokół PHP. Przykładem może być Sun (który stoi na podobnej pozycji z Javą). Czym najłatwiej zgromadzić społeczność wokół własnej platformy? Oczywiście - projektami. Im więcej projektów tym więcej zaangażowanych ludzi i osób oraz firm nimi zainteresowanych. Tymczasem, co robi Zend? Prze ślepo w jednym kierunku, mianowicie w stronę własnego Frameworka, który od ideału jest daleki.

Jeden framework nie zdobędzie serc wszystkich programistów tym bardziej, że w PHP korzystanie z gotowych rozwiązań do w dalszym ciągu rzadkość. Zamiast wspierać chociażby konkurencyjne rozwiązania Zend nie robi nic, nawet nie kiwa palcem by przyciągnąć do siebie projekty. Przykładem może być Cake PHP, wokół którego zgromadziła się pokaźna grupka osób oraz Prado, które jest rozwiązaniem zgoła innym, działającym na zupełnie innych zasadach. Czyżby Zend nie wiedział, że w mnogości tkwi siła? Najwyraźniej tak, nie wspierając społeczności PHP wiele traci. To działa w obie strony, tak samo jak Zend może liczyć na takie samo wsparcie społeczności jako ono na jego. PDO

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.