Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: Athlan, dodany: 29.01.2007 16:04, tagi: framework

Dziś ostatecznie zdecydowałem się w jaką inżynierię oprogramowania wejdę, co postaram się rozbudowywać i poświęcać temu czas. Postanowiłem zostać developerem Rapide Framework, propozycję współpracy dostałem dużo wcześniej, ale myśl o porzuceniu Vframe - nie ukrywam - bolała. Jakie wnioski? Nie ma sensu pisać wielkiego frameworka samemu… lepiej robić to w grupie ludzi, która zna się na rzeczy, zawsze ktoś Cię może poprawić, wesprzeć, doradzić. Rola całkiem często odwraca się, że to właśnie Ty pomagasz i doradzasz. Decyzja zapadła ostatecznie, na Vframe napiszę ostatnią aplikację w ferie. Będę sięgał do jego pojedynczych komponentów jeżeli będzie taka potrzeba, ale to będą wyjątki.

Dlaczego porzuciłem projekt? Poddałem się? Nie. Projektu nie porzucilem, ale nie będę go już rozwijał, nie poddałem się, bo nic nie pójdzie do kosza. Możnaby było zapytać: co ze starymi klasami? Rapide jest gotów przyjąć parę moich rozwiązań, a jeżeli nie będą one dołożone w oficjalnym wydaniu, mogę korzystać z nich jako pomoce (pluginy bądź biblioteki).

Decydującym argumentem jest tutaj niewątpliwie modularność Rapide. Adrian (prph) doskonale przewidział problemy, jakie mogą wystąpić przy dalszym toworzeniu frameworka. Prostym przykładem jest Config, który przyjmuje póki co dane jako tablicę, ale modularność aplikacji pozwala na dołączanie kolejnych możliwości, na przykład obsługe konfiguracji z poziomu plików INI, XML, itp. Drugim argumentem jest to, że pracujemy w grupie. Jak już wspomniałem w drugim akapicie jest to wspaniała sprawa, gdy grupa developerów pomaga sobie nawzajem, pozwala to na dalszy rozwój członka grupy.

Parę moich komponentów jest naprawdę dobrych, chociażby Image. Postaram się wingerować go do Rapide, lecz w sposób modularny, możliwe że ktoś napisze go za mnie, ważne są pomysły. Jeżeli macie jakieś osobiste refleksje dotyczące Rapide, odnoszę na oficjalne forum.

Autor wpisu: Athlan, dodany: 28.01.2007 17:02, tagi: framework

Dziękuję za dotychczasowe opinie, wraz z pojawieniem się nowych opcji, pojawiła sie również nowa dokumentacja. Zacznę od tego, co zostało dodane do myśli technicznej:

  • Dodano mapowanie całości core framewoka, czas działania diametralnie spadł, mapa jest tworzona dzien od ostatniej akutualizacji, lub gdy jakiejś klasy ni będzie w mapie. Jeżeli nie będzie jej po ponownym wygenerowaniu mapy, wówczas zostanie wyrzucony wyjątek.
  • W pliku konfiguracyjnym nie muszą być zdefiniowane wszystkie stałe, potrzebne sa tylko niezbędne, resztę Vframe jest w stanie dopisać sobie automatycznie, na domyślne wartości

Zmiany w funkcjonalności komponentów:

Vsession, Vuser - dodano możliwość odwołania się do danych jako tablicy obiektu, gdyż implementowany jest interfejs ArrayAccess Vcontroller, Vview, Vmodel - otrzymały implementację interfejsu ArrayAccess i najważniejszych aliasów dla komponentów Lang(), Session(), Input(), Url(). Dziedziczą z klasy VcommonMVC i Vattributes. Vattributes - dodana nowa klasa, która daje możliwość operowania na atrybutach (tablicy $_aAttributes) poprzez metody __set(), __get(), has(), remove(). Vinput - wprowadzone zmiany o ktore prosiliście, przy okazji bardzo mi się przydały w wykonaniu jednego z projektów. więcej: http://framework.vgroup.pl/read-input-data.html#4.7.1 Vlang - wykrywanie domyślnego języka użytkownika oraz wybranie odpowiedniego z dostępnych w aplikacji - główna myśl wersji 0.1.10, więcej: http://framework.vgroup.pl/read-languages.html#4.8.4 http://framework.vgroup.pl/read-uzytkownik.html#4.11.4 Zmienione nazewnictwo plików językow na skróty, zamiast Polish jest pl itd., więcej: http://framework.vgroup.pl/read-languages.html#4.8.1 Vuser - ustawianie języka użytkownika, więcej: http://framework.vgroup.pl/read-uzytkownik.html#4.11.4

Vframe 0.1.10 możecie pobrać z działu download: http://framework.vgroup.pl/download.html

Manual dostępny pod starym adresem: http://framework.vgroup.pl/manual.html

Dodany został DevServer, na którym stale działam, tam są publikowane natychmiastowe zmienay w CORE, które nie zostały opublikowane. Na devserwer tworzone są kolejne wersje fw: http://framework.vgroup.pl/devserver.html

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

Autor wpisu: Zyx, dodany: 27.01.2007 22:12, tagi: php

Wszedłem sobie dzisiaj na blog seaquesta, a tam notka z 17 listopada ubiegłego roku o polskiej społeczności PHP. Rzecz warta przedyskutowania, a poruszyła mnie, ponieważ sam od pewnego czasu zastanawiałem się nad sytuacją, mając za sobą doświadczenia WebCity.pl i OpenPB. Diagnoza Seaquesta jest całkiem niezła i w dużej mierze się z moimi poglądami pokrywa, aczkolwiek nakreślę wszystko od początku.

Autor wpisu: Athlan, dodany: 25.01.2007 21:51, tagi: php

Czasem potrzebujemy zabezpieczyć nasz skrypt autoryzacją. Kiedyś pisałem już o zabezpieczeniu autoryzacją po stronie serwera, jednak wymagało to nałożenia hasła na dany folder. Jest jakaś możliwość autoryzacji na dany plik? Odpowiedz brzmi: „tak”, ale musi on wysłać odpowiednie nagłówki.

Zanim przejdziemy do daleszej części artykułu zapoznajmy się z teorią. Aby zabezpieczyć nasz plik, należy wysłać request do serwera „WWW-Authenticate”, który umożliwi nam wprowadzenie danych. Jak przesłać? Tak jak inne dane do serwera np o kodowaniu, czy MIME… header(): header(’WWW-Authenticate: Basic realm=”Protected area!”‘); w miejsce realm=”” wpisujemy tekst, który pojawi się jako „etykieta” logowania, czyli komunikat, tak jak przedstawiłem na poniższym screenie:

Następnym nagłówkiem z jakim trzeba się zapoznać to wysłanie takiego żądania, aby uznał plik jako nieważny (no authorization), przykładem takiego pliku jakst folder, do którego nie mamy dostępu, wyświetla się komunikat 403 Forbidden. Takim samym sposobem zabezpieczymy nasz plik: header(’HTTP/1.0 401 Unauthorized’);

Ok, potrafimy odciąć autoryzację, wyświetlić okno logowania… i na tym się kończy. Aby w pełni wykorzystać autoryzację musimy jakoś przechwycić dane z logowania. Okazuje się, że są one wysyłane do tablicy $_SERVER pod kluczami „PHP_AUTH_USER” dla nazwy użytkownika i „PHP_AUTH_PW” dla hasła. Odzwierciedlając dostęp otrzymujemy: $_SERVER[’PHP_AUTH_USER’] oraz $_SERVER[’PHP_AUTH_PW’].

Przejdźmy do praktyki, nadajemy konkretne haslo i login, który wymagamy zanim zaczniemy wykonywać jakikolwiek kod…

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

Autor wpisu: Athlan, dodany: 21.01.2007 21:54, tagi: framework

Ostatnio nurtował mnie problem, jak mają być ułożone pliki we frameworku, tak aby można było je bardzo łatwo ładować poprzez __autoload(). Rozmyślałem nad sposobem zastosowanym w Zend Framework oraz moim - rzucić pliki niezależnie od ich nazw. Dwa linki, gdzie publikowałem swe przemyślenia, wyciągłaem wnioski, porównywałem wyniki:

Ostatecznie wygrał mój sposób. Kładę pliki tam, gdzie chcę, niezależnie od nazwy klasy. Zend Framework ma sztywno ustalone ścieżki klas, w zlaeżności od jej nazwy. Ci co mnie znają wiedzą, że nie lubię się ograniczać :)

No tak… wygrał sposób dotychczas stosowany w moim frameworku Vframe, ale jak rozwiązałem problem skanowania folderu Core za każdym razem? Hak bardzo prosty: tworzenie tzw. mapy frameworka. Czym jest owa mapa? Zwykłą zaserializowaną tablicą, która tworzona jest po pierwszym skanie zawartości frameworka. Po co tworzyć ją od nowa za każdym odświeżeniem strony, skoro można ją raz zapisać (przykład wypluten przez var_dump() mapy).

Na jakiej zasadzie to działa? Mapa zapisywana jest w pliku Vframe.map, to, co pokazałem w powyższym linku to jeden z elemetów mapy (wartość indeksu tablicy “files”). Są jeszcze dwa indexy: “date” oraz “version”. Jeżeli wersja frameworka zmieni się, lub minie dzień od wygenerowania mapy, wówczas jest ona tworzona raz jeszcze. Mapa frameworka trzymana jest bezpośrednio w jego folderze. Dlaczego? Ponieważ zawiera mapę samego siebie.

Podsumowywując:

  • zaoszczędziłem czas działania aplikacji
  • nie zmieniłem nazewnictwa klas
  • nie jestem uzależniony od nadawania nazw klas w stosunku do ich położenia
  • mapa aplikcaji jest na bieżąco aktualizowana, lub przy zmianie wersji ulega automatycznej zmianie

Myślę, że publikując wyniki “badań” rozwieje wiele wątpliwości “przeciwnikow” układu plików w Zend Framework.

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

Autor wpisu: Athlan, dodany: 20.01.2007 09:08, tagi: php, framework

Wprawdzie mój framewoek ma jak widać finalny układ plików, ale zaczyna mnie gryźć… przed startupem cały core jest skanowany, dzięki czemu mogę rzucać sobie klasy w katalogu core gdzie popadnie, moge stworzyć 5 folderów i potem dać klase. Mnie się on coraz to mniej podoba. Ostatnio przeglądałem Zend Framework dziesiąty raz, postanowiłem zebrać w kupę plusy i minusy mojego sposobu oraz sposobu wykorzystamyn w Zendzie.

Układ plików w Vframe:

(+) skanowanie core zapewnia porządek i elastyczność, mogę rzucić klasę gdzie popadnie (+) stosowanie nazw klas jest niezależne od ich położenia (-) czas działania nieznacznie się wydłuża

Układ plików w Zend Framework:

(+) nie trzeba skoanować core (-) nazwy klas są ściśle uzależnione od ich położenia (-) robi się mase folderów, w ktorych jest zazwyczaj po jednym pliku

Mimo tego, że moim zdaniem Zend ma więcej minusów przeze mnie wykrytych, jestem mu jakoś bardzie przychylny. Nie podoba mi się nazwa typu Zend_Folder_Klasa. Nie mam symapatii do „dolnych podkreśników”. Wymyśliłem sobie, że w moim fw mogę zastosować inny sposób oddzielania ukladu pliku w nazwie klasy. Odpowiednikiem Zend_Folder_Klasa byłoby wówczas VfolderKlasa lub VfolderPodfolderKlasa, lub po prostu Vklasa. Aby nie robić bałaganu, wszystkie wyjątli miałyby nazwę np. VexceptionCache, dzięki czemu nie tworze nowego folderu Cache, w którym jest tylko wyjątek. Tak to mam jeden folder z wyjątkami. To samo tyczy się interfejsów. Nazwa nie byłaby oddzielana podkreślnikiem, tylko kolejną wielką literą.

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

Autor wpisu: WojciechNaruniec, dodany: 20.01.2007 01:22, tagi: php, framework

Pojawiła się nowa wersja Zend Framework o numerze 0.7.0. W tym wydaniu głównymi zmianami jest wprowadzenie klas do obsługi lokalizacji oraz internacjonalizacji. Została też mocno rozwinięta polska dokumentacja frameworka. Główne zmiany to: Komponent do zarządzania lokalizacjami (L10N) Komponent do obsługi daty i czasu z uwzględnieniem lokalizacji Komponent do obsługi tłumaczeń (I18N) (w inkubatorze) Komponent do obsługi jednostek i ich konwersji Nowa [...]
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.