W najnowszym wpisie na internalsach, Johannes Schlüter ogłosił, że wersje RC3 php 5.2.14 i 5.3.3 powinny trafić do obiegu najdalej w piątek. Natomiast wypuszczenie finalnych wersji planowane jest na 22-iego lipca.
Po przeczytaniu wpisu na blogu Cyśka stwierdziłem, że jednak świadomość rozumienia istoty modelu w świecie PHP wymaga poprawy i stąd ten artykuł. Opiszę w nim jeden ze sposobów tworzenia warstwy modelu, a dokładnie metodologię DDD. Dla pobieżnego zapoznania się z tematem polecam Wikipedię, natomiast ja będę starał się rozwinąć ten temat tutaj i pokazać go na przykładach, czego większości opisów brakuje. Jeszcze słowem wstępu powiem, że metodologia DDD nie tylko mówi jak zaprojektować warstwę modelu, oprócz tego odnosi się również do prowadzenia samego projektu informatycznego ukierunkowanego na stworzenie gotowego produktu. Metodologia DDD w kwestii prowadzenia projektu mówi, że model domeny nigdy nie jest ukończony, jego powstawanie wiążę się ze stałym kontaktem z klientem. Rozmawiając z klientem porozumiewamy się z nim w języku domeny czyli w terminologii danego zagadnienia. Wielu z Was pewnie łapię się za głowę i pyta – po co to wszystko ? Przecież żeby postawić stronę wizytówkę nie potrzeba żadnej magicznej terminologii i kontaktów z klientem… I macie racje, generalnie metodologie DDD stosuje się do projektów o skomplikowanej logice, czyli generalnie do aplikacji dedykowanych. Nikomu raczej bym jej nie polecał stricte do budowania CMS-a, chociaż można wykorzystać pewne jej elementy.
Wracając do języka domeny. Zdefiniujmy sobie przykładowy problem, załóżmy, że mamy do wykonania dedykowana aplikację hurtowni internetowej w której będziemy obsługiwać klientów korporacyjnych. Rozmawiając z klientem będziemy używali takich terminów z języka domeny jak: kontrahent, faktura, księgowanie, przedstawiciel handlowy, towar, oferta handlowa, zamówienie. W tradycyjnym podejściu z pewnością kontrahenta i przedstawiciela handlowego nazwalibyśmy Userem, towar produktem, zamówienie koszykiem a oferta handlowa była by jakimś tam rabatem. Rozmawiając z klientem w sposób tradycyjny w przypadku jakichkolwiek błędów w naszej aplikacji spotykamy się z sytuacją gdy obie strony mówią niby o tym samym ale zupełnie co innego mają na myśli co generuje dodatkowe błędy. Miałem (nie) przyjemność pracować przy projekcie, w którym właśnie nastąpiło rozminięcie się terminologii pomiędzy klientem a wykonawcą aplikacji i powiem Wam, że nie życzę nikomu tego doświadczenia.
Pewnie u części z Was w tym momencie zaświeciła się nad głową żarówka i wpadliście na z pozoru świetny pomysł „ale co nas obchodzi język domeny, rolą projekt managera jest to, żeby nam przełożył język domeny na coś zrozumiałe dla nas programistów”. W metodologii DDD, kładzie się nacisk na to, by używać języka domeny również w kodzie (nazwy metod, klas, pól, zmiennych), dzięki temu gdy następują jakieś zmiany w modelowanym przez nas zagadnieniu (a jest to proces ciągły i nieskończony) możemy odnaleźć w naszych klasach metody, które dokładnie odpowiadają zachowaniu się modelowanej domeny. Efektem ubocznym takiego podejścia jest to, że programista uczestniczący w projekcie prowadzonym w terminologii DDD staje się stopniowo specjalistą w danej dziedzinie, a przynajmniej zaczyna się w niej orientować.
Podsumowując, w tym wpisie dowiedzieliśmy się czym jest Domain Specific Language i jaką rolę odgrywa w budowaniu modelu oraz jakie konsekwencje niesie ze sobą jego używanie bądź nie używanie. W drugiej części serii postaram się zaprezentować jak przełożyć DSL na konkretny kod.
Mam nadzieje, że zainteresowała Was ta tematyka i liczę na Wasze pytania i komentarze 
Niezależnie od rodzaju, wielkości i skomplikowania aplikacji internetowej można wyróżnić w niej kilka podstawowych (prawie zawsze występujących) elementów; autoryzacja, model, prezentacja danych, itp.
KontorX_DataGrid
Ten wpis chciałbym poświęcić bardzo powszechnemu elementowi – prezentacji, a dokładniej prezentacji danych tabelarycznych z j.ang. „data grid”. Notorycznie napotykamy ten element w prawie każdym panelu administracyjnym. Przybiera on różne formy w zależności od postawionych wymagań. Można wyróżnić:
Natywne PHP:
JavaScript + PHP:
Powyższe biblioteki implementują mniej lub więcej form prezentacji danych. Każda z nich wymaga wykonania kilku „ruchów” by je skonfigurować ale czy można prościej?… Tak. Dlatego chciałbym w tym wpisie omówić bibliotekę – KontorX – jest to biblioteka, którą nieprzerwanie rozwijam od prawie 3 lat. Bibliotekę KontorX zawiera w sobie wiele elementów a jednym z nich jest KontorX_DataGrid.
Biblioteka umożliwia elastyczne prezentowanie danych tabelarycznych w dowolny sposób i prawie w dowolnej formie. Poniżej przedstawiam główne cechy biblioteki:
)Powyższy opis może nie wiele mówić dlatego zapraszam do przykładów demonstrujących, niektóre możliwości komponentu: http://kontorx.widmogrod.info/#http://kontorx.widmogrod.info//KontorX/DataGrid/example1.php
Jeżeli korzystasz z ZF wystarczy że pobierzesz bibliotekę z Google Code umieścisz ją w include_path aplikacji i zaimplementujesz powyższy kod w kontrolerze wybranej akcji przekazując model danych (na chwilę obecną zaimplementowałem obsługę Zend_Db_Table, Zend_Db_Select, array).
Biblioteka posiada już zaimplementowany domyślny sposób prezentacji danych więc niczym nie musisz się martwić (jedynie tabelę możesz ostylować w/g własnych upodobań )
Wietrzenia domowej biblioteczki ciąg dalszy. Dzisiaj nie lada gratka dla osób zainteresowanych AJAXem. Mam dla was dwie książki o tej tematyce: AJAX i PHP. Tworzenie interaktywnych aplikacji internetowych oraz Ajax. Zaawansowane programowanie.
Jeśli chcecie zdobyć te książki, wystarczy że odgadniecie wagę mojego kota. Dla ułatwienia podam kilka szczegółów: kotka, wiek – niewiele ponad 3 lata, rasa – kotka europejska pospolita, kolor – rudy (rudy to nie kolor, rudy to charakter ;) ).
Na zgłoszenia czekam do końca jutrzejszego dnia (do północy 12.07.2010). Powodzenia!
Moda jest wszędzie. I nie chodzi mi tutaj o kraciaste koszule programistów. Programowanie, podobnie jak inne dziedziny naszego życia, ulega wielu wpływom. Programowanie w PHP ulega tym wpływom jeszcze bardziej. Dzieje się to głównie za sprawą opinii jaka za tym językiem się ciągnie. Programiści chcąc ją poprawić, chwytają się wszelkich możliwych sposób, by udowodnić, że PHP jest na czasie ze wszystkimi nowinkami / pseudo-standardami.
Jedną z takich nowinek jest bardzo popularny ostatnio MVC. Od dobrych kilku miesięcy (a może i lat) jakość aplikacji PHP oceniana jest po tych trzech magicznych literkach. Jeśli na pytanie “Czy Twoja aplikacja została napisana w duchu MVC?” padnie odpowiedź, że nie, wówczas od razu traci uznanie. Najzabawniejsze w tej całej sytuacji jest to, że niewiele osób wie, czym tak naprawdę MVC jest, oraz że nie jest to jedyna słuszna droga do tworzenia aplikacji. Jeśli spojrzymy na dowolne forum poświęcone programowaniu w PHP, bardzo szybko znajdziemy na nim dziesiątki tematów z pytaniami w stylu “Gdzie mam umieścić widok?” lub “Czy ta klasa to już model?”. Winę za to ponosi dosyć luźna interpretacja tego wzorca oraz techniczne ograniczenia języka. Zasadą przyświecającą MVC jest oddzielenie od siebie warstw aplikacji. I tutaj zaczynają się schody. Oddzielenie warstw może odbywać się na kilku poziomach. Można stworzyć jeden plik, w którym znajdzie się dostęp do danych, manipulacja danymi oraz ich prezentacja i będzie można powiedzieć, że taki plik został stworzony zgodnie z MVC (gdzie jest napisane, że każdy element tej układanki musi być w osobnym pliku?). Można również podzielić to na dziesiątki plików, dodać helpery, pluginy, router, dispacher i inne cuda. Reguły na to nie ma.
Czy jesteśmy skazani na MVC? Niestety tak. Podobnie jak kiedyś popularny był Singleton, tak teraz panuje moda na MVC (w najczystszej postaci). Stąd też nieco prowokujący tytuł. Zamiast na ślepo iść za modą, warto zastanowić się, czy w naszym przypadku ma ona rację bytu. Może okazać się, że jedna z literek jest nam kompletnie niepotrzebna, a może któraś z nich będzie wymagała dodatkowego podziału na kolejne elementy? W końcu może okazać się, że nasze każda literka w naszym MVC, ma swoje własne MVC w środku. Niestety nie ma dobrej alternatywy dla modelu wielowarstwowego. W chwili obecnej jest to najlepsze podejście to tworzenia aplikacji i tylko od nas zależy jak z niego skorzystamy.
Kanał ATOM
