• Weryfikacja poprzez upload pliku na serwer.
• Chwilowe dodanie meta-tagu do sekcji HEAD.

W stosunku do google, zmianie uległa u mnie weryfikacja pierwsza.

Sposób Google: Upload pliku bez zawartości (lub z dowolną) o nazwie jako hash aktywacyjny, np: <?php md5( secret-salt ) . '.html'; ?>

Mój sposób: Upload pliku ze stałą lub hashowaną nazwą o zawartości 32 znakowego hashu md5.

Zmienia się tylko zawartość pliku. Dlaczego? Niektóre strony zamiast zwracać kod 404 dla nieistniejących plików/podstron zwracają kod 200 (sukces). Wówczas trudno stwierdzić, czy jest to oczekiwany plik. Google dodatkowo sprawdza, czy strona zawsze zwraca kod 200, ale po co się babrać i wykonywać więcej requestów, jak można zrobić to trochę prościej. Jeżeli plik nie będzie fizycznie istniał na serwerze, a strona zwróci kod 200, skrypt musi oczekiwać w odpowiedzi tylko i wyłącznie hashu strony. Nazwa pliku na serwerze może być stała, ale niekoniecznie (dla większego bezpieczeństwa zalecane jest logiczne hashowanie nazwy pliku).

Przygotujmy zatem zarys klasy (od tego zawsze zaczynam):

• public function CheckFile($sUrl, $sFilename) funkcja sprawdzająca hash w pliku na serwerze.
• public function CheckMetatag($sUrl, $sTagName) funkcja sprawdzająca hash w metatagu.
• public static function Hash($sUrl) funkcja budująca hash na postawie adresu URL (jako że podajemy go jako parametr obu metod sprawdzających, zmienna jest łatwo dostępna dla systemu).
• public static function Metatag($sHash, $sTagName) generowanie kodu XHTML dla metatagu – metoda potrzebna nam przy podaniu użytkownikowi meta tagu oraz do prega w metodzie CheckMetatag();
• protected static function _Request($sUrl) tworzenie requestu za pomocą HttpRequest i zwracanie treści metodą getResponseBody() wspomnianej klasy.

Jako że komponent jest niejako zewnętrzną biblioteką, nie mogłem go wcisnąć w komponentu frameworka. Otrzymał status biblioteki: VframeLib_WebVeryfication.

Oczekiwane API:

var_dump(VframeLib_WebVeryfication::CheckFile('http://example.com/', 'Veryfication.txt')); // bool result
var_dump(VframeLib_WebVeryfication::CheckMetatag('http://example.com/', 'Veryfication')); // bool result

Gotowy kod:

http://athlan.pl/code/VframeLib_WebVeryfication

Uwaga. Kod jest w fazie testowej. Wszelkie Wasze komentarze będą uwzględniane przy poprawkach.

• Możliwość tworzenia grup routingów za pomocą wyrażeń regularnych (grupowanie regułek, aby przyspieszyć działanie).
• Automatyczne wczytywanie konfiguracji Vframe_Router_Advenced::PatternsBuild().
• Wydzielenie głębi konfiguracyjnej dla kontrolerów (kontroler News_Admin_Vcontroller ma plik: /Configuration/Controllers/Admin/News.php).
• Zaimplementowanie Cache_Engine (wzorzec fabryki) oraz silników: File, Memcache, APC.
• Zaimplementowanie Image_Engine (wzorzec fabryki), silnik GD.
• Zaimplementowanie Db_Layer (wzorzec fabryki), silniki MySQL, SQLite.
• Zniesiona została stała V_APP oraz V_APP_REAL.
• Dodanie nowego komponentu Vframe_Mail_Inbox (pobieranie poczty) oraz silnika Vframe_Mail_Inbox_Engine_Imap.
• Zabezpieczenie unikalnego klucza sesji frameworka, dodanie V_APP_SESSION_HASH.
• Zmiana struktury Exceptions oraz Interfaces – teraz klasy znajdują się w głównym pliku komponentu, nie posiadają wydzielonych plików.
• Dodanie pluginu Vframe_Controller_Front_Plugin_Gzip.

Konieczne zmiany w aplikacji:

• Pliki konfiguracyjne modelu Db_MySQL na Db_Layer_MySQL, analogicznie dla innych baz.

Zalecane zmiany:

• Wszelkie define() zamienić na Vframe::_() (argumenty analogiczne) oraz załadować główny plik konfiguracyjny po frameworku (aby uzyskać funkcję statyczną _() ).
• Usunąć V_APP_REAL.
• Aby użyć pluginu Gzip: $oFrontController->Plugin(new Vframe_Controller_Front_Plugin_Gzip(6)); gdzie 6 to stopień kompresji, jeżeli null, wówczas domyślnie 6.

Linki:

• Pobierz Vframe 2.3.1. (wszystkie wersje).
• Źródła online.
• Dokumentacja.
• Pełne repozytorium.

Od niedawna w sieci istnieje nasza strona na konkurs Diversity organizowany przez Motorolę o którym pisałem.

Witryna w dostępna pod adresem life-styles.pl prezentuje style życia z podziałem na kategorie:

• muzyka,
• sport,
• religie,
• moda,
• jedzenie.

Wykorzystuje komponent Vframe_Language i nie wymaga bazy danych. Jest to pierwsza (prosta) aplikacja oparta na Vframe 2.x z otwartym kodem źródłowym.

Przebudowana została struktura stałych frameworka. Dotychczas używał on zwykłych, wbudowanych stałych PHP w celu ustalania kluczowych zmiennych konfiguracyjnych (np. ścieżka kontrolerów). Pojawił sie problem przy tworzeniu aplikacji, gdy ta musiała pobrać pliki konfiguracyjne oraz użyć modeli z kilku innych. Framework powinien działać płynnie, używając wbudowanych rozwiązań, nie martwiąc się o ścieżki. Jak wiemy, nie można nadpisać stałej przypisując jej inną wartość. Taki przypadek został uznany jako jeden z 7 grzechów głównych programisty PHP.

Możliwie były 2 rozwiązania:

• Implementacja definicji “stałych” używając wbudowanego od wersji 2.0 wzorca Registry.
• Wdrożenie nowego rozwiązania, poprzez odwołanie się do Vframe::_(); ( public static function _( string $sParam, mixed $mValue ) )

Wybrałem drugie, ze względu na to, że nazwy Registry oraz stałych mogą się przez przypadek pokryć.

Vframe 2.2.0 jeszcze nie jest dostępny do pobrania w repozytorium.

Co w wersji 2.3?

PHP w wersji 5.3 idzie w bardzo dobrym kierunku. Zapowiada się implementacja magicznej metody __callStatic() analogicznej do __call(). Problem będzie w instalacji najnowszej wersji na polskich serwerach. W wersji 5.3 odkryto błąd, który tracił na wydajności (łączenie stringów poprzez znak kropki zużywał dużo więcej pamięci niż poprzez użycie .=). Może to przekona polskie firmy hostingowe do update’u paczki PHP. Póki co, __callStatic() można sobie zadeklarować ręcznie, a do działania wykorzystać eval().

Co za tym idzie klasa Vframe_Loader zostanie przebudowana używając __callStatic();

Tak oto powstała klasa obsługi formularzy oraz jego elementów. Użycie jest bardzo wygodne, po zainicjowaniu $oForm->init() nasz komponent wykonuje filtracje, a następnie walidacje danych wejściowych. Ewentualne błędy można wychwycić poprzez wywołanie metody $oForm->error(‘nazwa_pola’); – zwrócony zostanie string w przypadku wystąpienia błędu, null jeżeli go nie ma. Aby sprawdzić, czy wystąpiły jakieś błędy przy walidacji – nie podajemy parametry metody error: $oForm->error(); Zostanie zwrócona liczba błędów (jeden dla każdego pola), jeżeli 0 – możemy wykonać akcję.

Image by Deiru.

Dziś światło dzienne ujrzał Vframe 2.0, poprzednia wersja nie jest już rozwijana.

http://framework.vgroup.pl/repository/

Zobacz/Pobierz wydanie Vframe2

Narazie dostępny kod frameworka oraz prosta aplikacja (splash), niedługo pojawi się przykład CMS oparty na Vframe 2.0. W sferze planów przygotowywany jest VframeAdminGenerator tworzący panel administracyjny na podstawie plików konfiguracyjnych panel administracyjny.

Pierwszym zasadniczym irytującym błędem były podwójne myślniki wynikające z zamiany spacji na myślnik. A co jak będzie ciąg ” – “. Trzy myślniki z rzędu? Nieładnie to wygląda. Do Vframe 2 został dodany util niwelujący ten błąd.

Drugim problemem pisania aplikacji w Vframe 1.x było powtarzanie się takich samych rewrite w bazie. Klasa Vframe_Util_Rewrite obsługuje analizę stringów oraz przygotowuje nowy w ten sposób, aby żaden się nie powtórzył. Z bazy danych należy tylko wyciągnąć stringi LIKE ‘naszstring%’ i podać je klasie w formie tablicy asocjacyjnej. Do nowego stringu zostanie dodany numerek, bądź (uwaga) własny prefix.

Przykłady zastosowań:

http://cpaste.com/4079

Klasa:

http://cpaste.com/4078

Główną nowością w rebuildzie klasy użytkownika i ACL jest możliwość nadawania rang, co znacznie ułatwia pracę nad aplikacjami wymagającymi zaawansowanego dostępu do poszczególnych modułów aplikacji. Przykładowe wykorzystanie klasy użytkownika prezentuje się następująco:

[php]< ?php

$oUser = new Vframe_User;

// log in user
$oUser->Auth(true);
// add some groups with ranks
$oUser->setGroup(‘administrator’, 10);
$oUser->setGroup(‘moderator’, 2);
$oUser->setGroup(‘redactor’, 1);
// and one without rank… rank for this group will be set as 0
$oUser->setGroup(‘user’);
// we can also set only one with theese groups

// will output true
var_dump( $oUser->hasGroup(‘administrator’) );
// will output true, because group “moderator” has group rank 2
var_dump( $oUser->hasRank(2) );
// will output true, because user has greater ranks than 1, it can be rank 1 too…
var_dump( $oUser->isRank(1) );
// first will output true, second false
var_dump( $oUser->isRank(5), $oUser->isRank(11) );
// will output true, user is logged in
var_dump( $oUser->Auth() );

?>[/php]

Kolejnym ważnym elementem jest konfiguracja warstwy dostępu do kontrolera. Przedstawia się ona mniej więcej tak:

[php]< ?php

$aConfig = array
(
'access' => array
(
// allow ranks 1, 2 and group ‘b’
‘allow’ => array(1, 2, ‘b’),
// allow only group ‘a’
‘allow’ => ‘a’,
// allow users with rank 4 or greater
‘allow’ => 4,

// so… forget about above exaple, and…
// let’s create access filter for allow users without banned group
‘allow’ => ‘user’,
‘deny’ => ‘banned’,
),
);

?>[/php]

Konfigurację możemy przedstawić w dowolnym formacie: php array, xml document lub ini configuration.

To na tyle : ) Myślę, że wystarczy wszystkim deweloperom.

• Zupełnie nowe 3 routery, podstawowy (bazujący na tablicy $_GET), rewrite (separator “/”, “,” lub inny do sprecyzowania, elastyczny na tyle, że nie trzeba mieć modrewrite na serwerze) oraz zaawansowany bazujący na wyrażeniach regularnych adresu. Routery są w pełni konfigurowane, w zasadzie nie ma ograniczeń co do pozycji parametrów i ich imion.
• Zaawansowana obsługa sesji oferująca dopinanie swoich handlerów z dwoma gotowymi (pliki oraz baza danych). Obsługa sesji implementuje interfejs Countable, dzięki czemu szybko można wyciągnąć i zcacheować ilość osób online. Pełna konfiguracja ciastek wysyłanych na potrzebę implementacji sesji.
• Obsługa baz danych oparta na PDO, autoukładanie formatowanie zapytań.
• Modularny Input, dane get, post, files, server są przechwytywane przez pluginy, dzięki czemu można dopinać sobie swoje wtyczki na potrzeby konkretne aplikacji, bądź całego frameworka. Jednym z pluginów jest parsowanie informacji o domyślnym języku użytkownika oraz przeglądarki z danych wejściowych.
• Klasa użytkownika oprócz przystosowywania grup będzie mogła nadawać im rangi, dzięki czemu nie trzeba sprawdzać dziesięciu grup usera, tylko rangę > 10. Analogicznie do identyfikacji grupy użytkownika hasGroup(), można odwołać się do rang – hasRank().
• Zaawansowany parser konfiguracji – wykrywa jedno z 3 rozszerzeń oraz dodaje domyślne – php. Dostępne czytniki plików konfiguracyjnych to XML, PHP Array oraz INI. Możliwość odpisania swoich sterowników, które są używane w zależności od rozszerzenia pliku konfiguracyjnego. Nieskończona głębia grup konfiguracyjnych.
• Cache. Tak jak w przypadku plików konfiguracyjnych występuje tu możliwość nieskończonego zagłębienia cache w grupy. Cache obsługiwane przez 3 podstawowe silniki: pliki, baza danych oraz Memcache.
• Backend. Podobnie jak w Symfony w Vframe pojawią się 2 dodatkowe aplikcje. Backend oraz system modułów. Backend generuje instalatory do baz danych oraz ma możliwość ustalenia dowolnej ilości dowolnych pól danych. Akcje: dodaj, edytuj, usuń, filtruj, szukaj.

Nie podaję terminu zakończenia prac, jest on niepewny, najważniejsze żeby wszystko było stabilne. Nową wersję piszę ze względu na własne potrzeby, backend na ciągłość powtarzania tych samych operacji.

Mechanizm automatycznego ładowania potrzebnych nam klas jest bardzo dobrym sposobem na zrelaksowanie się poprzez brak przymusu ręcznego ładowania plików potrzebnych do działania aplikacji. Znajdźmy receptę na owe pytanie przedstawiając dwa najpopularniejsze sposoby trzymania klas w np. frameworkach.

• Zend Framework i Rapide mają dość sztywną, lecz nie wymagającą specjalnego kombinowania technikę umieszczania plików w core. Sposób nazewnictwa jest bardzo prosty: Folder_Subfolder_Klasa – owy zapis odnosi się do ./Folder/Subfolder/Klasa.Class.php.

• W moim frameworku Vframe zastosowałem technikę, w której pliki leżą sobie „wolność w core, nazewnictwo klas nie tyczy się ich ścieżki, np. NazwaKlasy może odnieść się do ./NazwaKlasy.Class.php lub ./Folder/Subfolder/ NazwaKlasy.Class.php.

Spróbuję opisać drugi – mój – sposób na ładowanie plików z core aplikacji. Potrzebna nam będzie klasa, która jest w stanie przeskanować całe core i zapisać je do tablicy. Aby było łatwiej, skan zostanie zaserializowany do pliku jako mapa folderu. Co jeżeli plik nie będzie istniał w core? Wówczas mapa zostanie stworzona od nowa, jeżeli to nie pomoże – wyrzucimy wyjątek.

Projektujemy naszą klasę, nazwiemy ją przykładowo Autoload, metody:

• Load($sLibrary, $bRemapped = false) – metoda która będzie odpowiedzialna za załadowanie pliku oraz (jeżeli nie będzie istniała) stworzenie tablicy plików. W wypadku braku pliku zostanie ponownione wywołanie metody tworzenia mapy plików z przymusowym przeskanowaniem folderu klas oraz tym samym odpalenie metody samej siebie z przyjęciem drugiego jej parametru na true – brak ponownego skanowania folderu i wyrzut wyjątku.

• Map($bUseTemp = true) – metoda odpowiedzialna za stworzenie tablicy z plikami na podstawie pliku mapy poprzez odserializowanie danych w nim zapisanych. Jeżeli parametr otrzyma wartość false lub plik mapy nie będzie możliwy do odczytu, wówczas tworzona zostanie mapa, zapisana do pliku mapy oraz do tablicy klasy.

• FormatName($sLibrary) – metoda formatująca nazwę klasy: Klasa.Class.php

Wykorzystamy trzy stałe:

• const _LibDir – określa ścieżkę folderu z klasami

• const _LibSurfix – surfixy plików (.Class.php)

• const _LibMap – ścieżka i nazwa pliku mapy

Potrzebna będzie nam jeden statyczny, prywatny parametr klasy, który jest sam w sobie jej singletonem, więc każda instancja klasy będzie z niego korzystała:

private static $_aCoreMap = array();

Ok, teraz wystarczy użyć funkcji __autoload() i wykorzystać naszą klasę:

[php]function __autoload($sLibrary)
{
try
{
Autoload::Load($sLibrary);
}
catch(AutoloadException $oException)
{
// some message to display
die(‘Autoload failed: ‘ . $oException->getMessage());
}
}[/php]

Tworzymy osobisty wyjątek dla autoloadera:

[php]class AutoloadException extends Exception
{

}[/php]

oraz samą klasę:

[php] class Autoload
{
const _LibDir = ‘Core/’;
const _LibSurfix = ‘.Class.php’;
const _LibMap = ‘Map.tmp’;

private static $_aCoreMap = array();

public static function Load($sLibrary, $bRemapped = false)
{
if(!count(self::$_aCoreMap))
self::Map();

$sLibraryFile = self::FormatName($sLibrary);

if(!isset(self::$_aCoreMap[$sLibraryFile]))
{
if($bRemapped)
// if we remapped core and library dosen’t exists – throw an exception
throw new AutoloadException(‘Library “‘ . $sLibrary . ‘” has not been found in directory map!’);
else
{
// ok, let’s go map core again without using map from file
self::Map(false);
// try load class from core directory again…
self::Load($sLibrary, true);
}
}

require_once(self::$_aCoreMap[$sLibraryFile]);
}

public static function Map($bUseTemp = true)
{
// if map is ok and we counld use it, get the map from file…
if($bUseTemp && is_readable(self::_LibMap))
self::$_aCoreMap = unserialize(file_get_contents(self::_LibMap));
// …unless we have to scan core and make map
else
{
// clear array and remamp directory
self::$_aCoreMap = array();

foreach(new RecursiveIteratorIterator(new RecursiveDirectoryIterator(self::_LibDir)) as $oFile)
{
$sFile = $oFile->getFilename();

if(isset(self::$_aCoreMap[$sFile]))
throw new AutoloadException(‘Core duplication “‘.$sFile.’” found!’);
else
self::$_aCoreMap[$sFile] = $oFile->getPathname();
}

// ok, save map to file
if(!file_put_contents(self::_LibMap, serialize(self::$_aCoreMap)))
throw new VframeException(‘Cannot create core map!’);
}
}

private static function FormatName($sLibrary)
{
return $sLibrary . self::_LibSurfix;
}
}
?>[/php]

Całą paczkę klasy i zastosowań możecie pobrać tutaj.

NQ.pl było jednym ze sponsorów, ale również obserwatorem konkursowych zmagań. Liczba prac była duża i nie mogliśmy zapoznać się z każdą z nich.

Kilka prac szczególnie przypadło nam do gustu, dlatego też postanowiliśmy dodatkowo wyróżnić dwie prace:
Vframe framework, autor: Piotr `athlan` Pelczar oraz Logger, autor: Mateusz `CyberBoB` Kaczmarek.

Autorzy tych prac otrzymują od nas darmowy pakiet NQ.developer pozwalający na utworzenie pięciu repozytoriów SVN oraz projektów zarządzanych przez Trac.

Nie ukryję, że jestem dumny z mojego projektu. Jednakże ten jest już zamknięty (powstają na nim ostatnie juz aplikacje), gdyż zostałem developerem Rapide framework. Ci, co stanęli na podium oraz wyróżnieni otrzymają dyplomy lub zaświadczenia na wzór tego. Niech to będzie motywacją do wzięcia udziału w konkursie dla tych, którzy nie wystawili swoich prac przed publiczność.

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.

• 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

Wersję 0.1.10 zgłosiłem do konkursu art.php.pl , projekt możecie oglądać tutaj.

• Notka na blogu
• Temat na forum.php.pl

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 wypluty 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.

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ą.

Jeżeli wdrożyłbym owy sposób, wówczas zmieniloby się 40% nazewnictwa klas. Następnym, że tak powiem „kompleksem‿ jest oddzielenie klas odpowiedzialnych za MVC od klas funkcjonalnych mojego fw. Obecnie trzymam je w folderze Mvc. Zapis kontrolera w nowym schemacie działania miłby postać VmvcController. ſeeeee, średnio mi się podoba… chociaż…

Kwestię zostawiam w fazie przymyślnia i omówienia przez opinię publiczną. Jeżeli wdrożyłbym owy sposób ulokowania plików, wyszłaby całkiem nowa wersja fw już ze znaczącymi zmianami. Być może pojawi się stosowny temat na forum.php.pl.