Przedstawiam Wam dziś klasę widoku - jest to alternatywa dla systemów szablonów. Dzięki tej klasie możecie łatwo oddzielić logikę aplikacji od jest wyglądu.
Opis i przykłady użycia znajduje się tu:
http://nospor.pl/klasa-widoku.html

Download (klasa wraz z przykładową aplikacją):
http://nospor.pl/download/idfolder/31/

ViewPluginBase dał bym jako abstract.
$tpl nazwa szablonu - ustalał bym to w konstruktorze.
View::CreateInstance(), jaki sens ma ta metoda?

Cześć.

A ma coś lepszego / innego niż istniejące już systemy szablonów czy raczej sztuka dla sztuki?

A ma to tu jakieś znaczenie? (tak wiem, należy pisać poprawnie z logiką OOP )
No nie do końca. Bo to akurat jest ustawiane akurat dla tego widoku. Inne mogą tego nie potrzebować (patrz niżej)

Taki, że jak chcemy wygenerować sobie nowy widok, który nie jest zanieczyszczony zmiennymi, które dodawaliśmy do aktualnego widoku, to w szybki sposób pobieramy sobie nowy obiekt i po sprawie. Przy dużych projektach zdarzało mi się nie raz potrzebować tego, by przypadkiem nie doszło do konnfliktu zmiennych

O jakich systemach mówisz? Bo jeśli o systemach ala Smarty to jak już pisałem: ta klasa jest alternatywą wlaśnie dla nich. Jeśli masz na myśli inne, to o niczym innym nie słyszałem
Sztuak dla sztuki? Nie, ja z tego korzystam, mam to dostosowany pod cały mój system

1. Wszystkie właściwości klasy są statyczne, za wyjątkiem tablicy zmiennych, pytanie po co? Nie lepiej uczynić je prywatnymi i dorobić do nich odpowiednie gettery/settery, które dla przykładowo katalogu szablonów/wtyczek określą jasno ścieżkę z "końcowym" separatorem, bo niby kto ma wiedzieć czy ścieżka ma być w postaci /path/, /path, a może path/? To samo tyczy się rozszerzeń: .phtml, phtml. Setter dla takiej właściwości załatwiłby sprawę.
2. Może się czepiam, ale co do błędów: Może lepiej zastosować kody zamiast wiadomości (zwłaszcza, że dałeś polskie, to może komuś bardzo przeszkadzać, jeśli reszta silnika śmiga inaczej). Wtedy każdy mógłby dostosować błąd/przekierowanie czy cokolwiek innego z zewnątrz na własne potrzeby.
3. Konwencja nazewnictwa, też pierdoła, a jednak ktoś kiedyś napisał mi (z czym teraz zgadzam się w 100%), że to bardzo może wadzić, gdy masz w aplikacji Klasa->Metoda, klasa->metoda_inna, klasa->jakasMetoda, etc.. Może po prostu najlepiej wykorzystywać już powszechne PSR-0/1/2?
4. Prócz samej metody Escape, zastosowałbym jakiś menadżer do filtrów, w końcu może być więcej takich przydatnych funkcji, mógłbyś też pokusić się o takie drobiazgi jak ładowanie JS/CSS i inne przeróżne helpery do szablonów.

1. Brak wsparcia dla PSR-0 oraz Composera; Brak repozytorium na jakimś publicznym VCS-ie. Bardzo utrudniasz ludziom wykorzystanie tego.
2. Przydałoby się dodać do projektu "całą otoczkę" opensource'owych projektów.
3. Nadużywanie czy wręcz błędne używanie elementów statycznych dosyć mocno utrudniać będzie pracę z tą biblioteką.
4. Po co korzystasz z __get()/__set() zaciemniających jedynie kod i mogących prowadzić do problemów z zachowaniem wstecznej kompatybliności?
5. Potworki debug_backtrace() + trigger_error() zamiast wyjątku?
6. Funkcja escape nie jest bezpieczna - przepuszcza znak apostrofu, co już może prowadzić do błędów. W dodatku brakuje innych form escapeowania niż HTML. Taki Twig ma aż 5 metod escapeowania.
7. Dziwne konstrukcje w kodzie, przykład:

[PHP] pobierz, plaintext 
public function Render($tpl, $data = null) {
		if (!empty($data) && is_array($data)){
			foreach ($data as $k => $v){
				$this->Set($k, $v);
			}
		}
		$this->Get($tpl, true);
	}
 
// dlaczego nie
public function Render($tpl, array $data = array) {
		foreach ($data as $k => $v){
			$this->Set($k, $v);
		}
 
		$this->Get($tpl, true);
	}
[PHP] pobierz, plaintext 

@dipter
ad1) Mi pasuje tak.
ad2) Pewnie masz rację. Wycinałem tę klasę z własnego systemu i tak mi zostało
ad3) No zgadza się, nie ma psr
ad4) Nie widzę problemu byś sobie dodał jeśli potrzebujesz

@Crozin
ad1) Nie ma psr, nie ma composera. Brak publicznego repo? Jest download - ściągasz - masz. Naprawdę nie wiem jaki tu problem
ad2) Nie rozumiem
ad3) Co tu jest utrudniane?
ad4) A co wg. Ciebie będzie alternatywą na przypisywanie zmiennych, tablic i obiektów? Dla mnie to jest najprostrzy i najlepszy sposób. Masz inny - chętnie wysłucham
ad5) Wiedziałem że znajdą się fanatycy wyjątków i już pierwszy jest
NIe używam wyjątków gdy nie widzę potrzeby. Brak zdefiniowanej zmiennej, do której ktoś się próbuje odwołać nie jest dla mnie żadną sytuacją wyjątkową, szczególnie w kontekście całego php, gdzie to również nie jest jakimś specjalnym problemem.
ad6) Nigdy nie miałem potrzeby jakoś bardziej coś escapować. htmlspecialchars w 95% przypadkach wystarcza i dlatego dodałem tylko to. Jeśli ktoś ma specjalne potrzeby, nie widzę by dodał swoje escapy.
ad7) Przyzwyczajenie

ps: w jakieś psr i inne wynalazki będę się bawić, gdy php 5.3 będzie popularne i wszędzie. Póki oszczędzam sobie i innym problemów.
Zaś ci co korzystają nagminnie z autoloaderów naprawdę nie widzę problemu, by sobie jedną klasę zaincludowali po staremu

1. Gdyby to było tylko dla Ciebie, a w chwili obecnej to udostępniasz dla innych, to tak, mogło by Ci to pasować. Ale rzucasz kłody pod nogi innym, bo przez takie coś nikt dokładnie nie wie jak ma korzystać z klasy bez zagłębiania się w kod.
2. Prócz samych wiadomości, to tak jak wspomniał Crozin: debug_backtrace(), trigger_error() do wyeliminowania. To żaden fanatyzm, po prostu jest to chyba najmądrzejszy i najbardziej wygodny sposób obsługiwania właśnie takich sytuacji.
3. To może warto z tego w końcu skorzystać.
4. Właśnie widzę, bo na moment obecny ta biblioteka nic mi nie oferuje, a sam mechanizm można upchać do jednej metody render. Dając system szablonów (fakt faktem to raczej ładowarka widoków phtml/php) powinieneś dostarczyć przeróżne interfejsy i helpery, które w jakimś stopniu poprawią jakość kodu i zaoszczędzą czasu przy filtrowaniu/dołączaniu różnych elementów/plików.


Na większości hostingach jest już PHP 5.4 jako standard, więc 5.3 niedługo będzie jak 4/5.1/5.2..

ad1) Wyjaśni mi wkońcu ktoś o jakich tu kłodach mowa? Co mają zmienne statyczne, które na dobrą sprawę pewnie nikt zmieniać nie będzie, do rzucania kłód....
ad2) Nie używam wyjątków gdy nie ma potrzeby. Tutaj nie ma takiej potrzeby. W żaden sposób klasa na tym nie biednieje. ps: witam drugiego fanatyka wyjątków
ad3) Już wyjaśniałem: jak php5.3 będzie standardem, to zacznę tego używać. Póki co nie zamierzam sobie a ni innym rzucać kłód pod nogi
ad4) Używam tej klasy w kilku dużych moich projektach. Zaspokaja 100% moim potrzeb. NIe wiem jak Ty masz potrzeby, ale naprawdę nie widzę problemy byś rozszerzył klasę o te pare metod które potrzebujesz.
A jeśli to są naprawdę rzeczy, które są używane przez wielu to wymień jakie, wstawię je sam.

Zaprezentowałem alternatywę dla systemów szablonów, które moim zdaniem są przerostem formy nad treścią.
Jeśli czegoś tu brakuje, to naprawdę nie widzę problemu dodać. Niestety nie borykam się widać z takimi problemami jak Wy i nie mam aż takich potrzeb, więc klasa nie zawiera funkcji, które potrzebujecie. Naprawdę, daj cynk - a dodam.

O publicznym repo wspomniałem tylko ze względu na Composera. W przypadku, gdybyś nie miał dodanego swojego projektu do jednego z repozytoriów Composera, zawsze można poinformować Composera by skorzystał właśnie z VCS-a do pobrania. Tobie chyba nie muszę tłumaczyć wyższości wszelkiego oprogramowania do zarządzania zależnościami od ręcznego dodawania bibliotek?
Chodziło mi wszelkiego rodzaju informacje dot. licencji, zgłaszania błędów, wspomnianego wcześniej Composera/VCS-a czy chociażby autora (brak maila/innej formy kontaktu). Wiem, że to nie jest "poważny, open sourceowy projekt", a prosta klasa do obsługi prostych zadań; wiem, że to dział gotowe rozwiązania, a nie oceny, ale jeżeli już udostępniasz coś publicznie rób to porządnie. Szczególnie, że wiem, że nie jesteś początkujący.
Najprostszy przykład: nie utworzysz równolegle dwóch obiektów szablonu z różną konfiguracją, czego mógłbyś potrzebować na przykład przy wysyłce maili (szablony w osobnym katalogu).
Nie używać czystego PHP, tylko jakiegoś narzędzia ze wsparciem dla czegoś w rodzaju ExpressionLanguage znanego chociażby z JSF czy PHP-owego Twiga.
1. Potrzebowałeś backtrace'a, który jest udostępniany przez wyjątki. Zamiast tego zrobiłeś własny, który w dodatku pokazuje jedynie jeden element całego backtracea.
2. "Poprawne" obsługiwanie nieistniejących rzeczy jakie zaprezentowałeś i jakie znamy chociażby z PHP w połączeniu z ignorowaniem błędów to przyczyna z 15-20% nudnych tematów w dziale przedszkole, i dziesiątek godzin spędzonych na poszukiwaniu literówek i wtf'ków z niewiadomej przyczyny.

[PHP] pobierz, plaintext 
<?php
$a = 'blah\' onclick=\'KOD JAVASCRIPT';
?>
<p title='<?php echo htmlspecialchars($a) ?>'>sadada</p>
[PHP] pobierz, plaintext 

To nie jest specjalna potrzeba.

PHP 5.3 ma już prawie 4 lata i jest powszechnie dostępne. Na prawdę powinieneś już zrezygnować ze starszych wersji w przypadku nowych projektów...
Tutaj właśnie poprzez Twoje nie trzymanie się konwencji, które po wielkich bólach w końcu pojawiają się w świecie PHP, rzucasz kłody pod nogi. Szczególnie, że trzymanie się konwencji na prawdę nie tworzy dodatkowego nakładu pracy z Twojej strony.

A to jeszcze nie jest? o.O

O ile w takim linuxie to jest zajebista sprawa, to póki co żeby bawić się czymś takim w php to pierwszy raz słyszę. Człowiek starej daty jestem

No jak ktoś to ściąga ode mnie ze strony to chyba wie, gdzie ma zgłaszać błędy

Dziękuję, wkońcu mi wyjaśniono te kłody
Faktycznie, masz rację, nie sądziłem, że ktoś może potrzebować oddzielnych katalogów kiedykolwiek. Przez tyle lat jak programuje, nie widziałem takiego cuda, a wysyłkę maili realizowałem nie raz, stąd też i do głowy mi nie wpadło coś takiego. Naprawdę w praktyce takie rzeczy się dzieją? Na upartego można zmienić wartosci tych zmiennych a po odpaleniu widoku powrócić do starych

Jak już pisałem ja jestem człowiek starej daty i takich super hiper wypasionych pro bzdur nie używam. Naprawdę nie lubię ani sobie ani innym komplikować życia.

Ba, bo tylko jeden jest potrzebny.

No wybacz, ale jak ktoś nie umie odbierać błedów to jego problem. Skoro nie opanował tej techniki w czystym php to nie zamierzam go edukować w widokach.

Czemu uważam, że tutaj wyjątek jest nie potrzebny? Nie wyobrażam sobie sytuacji, że moja strona ma nagle przestać się normalnie wyświetlać tylko dlatego że z jakiegoś powodu zniknęła jakaś zmienna czy zninkął plugin z wyświetlaniem gdzieś na boku strony paru ostatnich komentarzy....

Jak pisałem naprawdę tego nie potrzebowałem. A nie potrzebowałem z bardzo prostej przyczyny: staram się pisać poprawny kod html. Używanie apostrofów do łapania atrybutów tagów jest nie poprawnym sposobem. Do tego używa się cudzysłowi. Wystarczy trzymać się tej prostej zasady i życie staje sie prostrze

Może swoje lata i ma, ale ciągle napotykam na serwery, gdzie php5.3 to jeszcze odległa przyszłość.

Nie, niestworzy mi to dodatkowego nakładu pracy. Stworzy natowmiast dodatkowy nakład pracy gdy natrafi na serwer bez php5.3

Widać nie

edit:
Jeszcze powrócę do zmiennych statycznych. Napisałeś Crozin, że jak ktoś chce nowy obiekt z innymi lokalizacjami to ma problem.
Ja zaś skolei dałem zmiennej statyczne właśnie spowodu odwrotnej sytuacji: gdy ktoś chce nowy obiekt z dokładnie takimi samymi lokalizacjami co główny widok. Gdyby to były zmienne obiektu, musiałby je na nowo ustawiać na takie same jak ma obiekt główny. ALbo pisać klasę dziedziczącą i nadpisywać metode CreateInstance. A tak nie musi nic takiego robić. A sytuacja, gdy ktoś potrzebuje nowego obiektu ale z tymi samymi parametrami wydaje mi się częstrza niż Twoja.

edit2:
@Crozin z tą otoczką to oczywiście masz rację. Juz wrzuciłem poprawioną paczkę. Pisałem wcześniej szybko i zupełnie o tym zapomniałem

Może jeszcze mi powiesz, że o narzędziach do budowania projektów Ant, Maven, Phing, wspomniany wcześniej Composer itp. itd. też nie słyszałeś? Chcesz wspierać PHP 5.2 i starsze... na prawdę pora na lekkie odmłodzenie swojego warsztatu.
A co jak odziedziczę po kimś projekt, gdzie Twoja biblioteka będzie już w użytku? Tyle dobrze, że Twojego bloga da się wygoogleać po Twoim imieniu i nazwisku.
Tak, i cała masa innych też. Ja też nie przewidzę całej masy przypadków, które Ty byś nazwał powszechnymi. Dlatego tak istotne jest pisanie wg reguł i standardów oraz pisanie testów. Te ostatnie w miarę szybko pozwalają wyłapać kompletnie spierniczony interfejs biblioteki.
Przed udostępnieniem biblioteki pisanej pod siebie szerszej publiczności, niemal zawsze trzeba coś poprawić.
Takie coś to ostateczność, jak się trzeba ze słabą biblioteką obchodzić, bo alternatywy nie ma, a autor poprawić niczego nie chce. Apropos alternatyw - nie napisałeś w czym Twój kod jest lepszy od istniejących, które część z nas zna, posiadających sporą społeczność. Jaki jest killer feature tej biblioteki?
Te cuda z reguły powstają z potrzeby i rozwiązują jakieś problemy. Jak są dobrze napisane to nie tworzą też zbyt wielu problemów. Mimo iż kiedyś twierdziłem inaczej, czyste PHP słabo się sprawdza w roli szablonów. Pomijając trywialne przypadki.
Bardzo, bardzo, bardzo złe podejście. Najmniejszy błąd powinien skutkować wywaleniem całej strony i cofnięciem wszystkich zmian jakie mogły zajść w systemie (patrz: m.in. transakcje). Wyobraź sobie, że masz formularz i przez jakąś głupią zagubioną zmienną nie wyświetlił się przy nim odpowiedni komunikat. Użytkownik klika szczęśliwy, a po przeładowaniu strony wielkie zdziwienie bo na koncie brakuje 100 zł. Czemu? Bo programista uznał, że jak się nie wyświetli wielki komunikat z informacją, że dana akcja jest płatna to nic się nie stanie.

Swoją drogą, wyjątki nie służą do obsługi sytuacji wyjątkowej tylko do obsługi błędów.
Zarówno XML jak i HTML - o porąbanym HTML5 nie wspominając - wspierają wartości w apostrofach: http://www.w3.org/TR/REC-xml/#NT-AttValue Sam też z tego staram się nie korzystać, ale można to robić, jest to jak najbardziej poprawne i wiele osób to robi. Pisałem już, że udostępniając coś publicznie, nie można wrzucić kodu pisanego stricte pod własne preferencje. Mówiąc wprost: Twój system szablonów polega na chwilę obecną przy najbardziej trywialnym zadaniu, jakim jest ochrona przed XSS.
Musiałeś zachować kompatybilność z PHP <5.3? OK. Ale i tak powinieneś trzymać się standardów (chociażby nazewnictwa klas).

Nie, nie jest. Co jeżeli będę mieć jakąś metodę wywołującą Twoją metodę od renderowania?

[PHP] pobierz, plaintext 
function a() {
  $dane = ...;
 
  return $this->abc('bla1', $dane);
}
 
function b() {
  $dane = ...;
 
  return $this->abc('bla1', $dane);
}
 
function c() {
  $dane = ...;
 
  return $this->abc('bla2', $dane);
}
 
function abc($szablon, $dane) {
  $dane->set('xxx', '123');
 
  return $this->twojObiekt->render($szablon, $dane);
}
[PHP] pobierz, plaintext 

Tutaj backtrace co najmniej dwóch odwołań wstecz jest potrzebny.

EDIT:
Whoa, whoa... to przecież wystarczy utworzyć sobie obiekt raz i korzystać z tego samego tam gdzie potrzebujesz? Albo utworzyć sobie fabrykę/repozytorium obiektów View? Każde z tych rozwiązań jest bez porównania lepsze od użycia zmiennych statycznych.

No, nie jest ze mną aż tak źle, anta używam nagminnie

Tak, tak, jak już pisałem w poprzednim poście dodałem już otoczkę

Nie napisałem, bo nikt mi nie napisał jakie są inne tego typu. Jeśli są tylko systemy szablonów, które mają swóją składnię, którą potem i tak kompilują do kodu HTML/PHP to moja klasa jest właśnie alternatywą dla takich systemów, które moim zdaniem nic nie wnoszą.
Jeśli zaś są inne, które operują na takim mechaniźmie jak moja, to chętnie poznam.

Chcesz mi powiedzieć, że inne systemy szablonów, jak nie ma zmiennych to plują wyjątkiem? Chyba za długo jeździłem na smartim

No cóż, dla mnie nie polega, gdyż piszę poprawnie No ale masz rację, muszę uwzględnić innych.

W 95% procent przypadków tak właśnie robię. Tworzę jeden widok i z niego korzystam. Zdarzają się jednak przypadki, gdy potrzebuję nowego widoku, który nie jest "zaśmiecony" zmiennymi, które poprzypisywano w międzyczasie. Wówczas tworzę nowy widok.


podsumowanie:
Na swoją obronę dodam, iż klasę pisałem pod siebie gdy pozbywałem się kobyły smartiego, która nic prócz kobylastości i braku kompatybilności w nowszych wersjach, nie wnosiła. Zaś moja klasa jest lekka a w widokach mogę robić co mi się zapragnie nie będąc ograniczonym przez durną składnie danego systemu szablonów.
Na FB ktoś mnie poprosił o publikację jej. Na szybkiego więc wydzieliłem klasę z mojego systemu i opublikowałem. Głównym zadaniem publikacji było pokazanie prostej i szybkiej alternatywy, by pokazać samą idee, że można pisać widok również bez niepotrzebnego zaprzęgania dzikich kobylastych klas. Każdy zaś potem może to dostosować pod siebie jeśli by miał ochotę.
Jak już pisałem klasa ta spełnia 100% moich potrzeb i nie muszę się martwić gdy wyjdzie jakaś nowa wersja, że jak się przesiądę to nie odpalę aplikacji.
Parę rzeczy uwzględnie co tu podałeś i podrzucę poprawkę, dziękuję za opinie. Z niektórymi się nadal nie zgadzam, ale dyskusja była bardzo ciekawa i produktywna. I wcale to nie znaczy że musi już być jej koniec

ps: @Crozin dostałeś PW w którym proszę o parę dodatkowych rad w pewnej sprawie?

Tak, albo przynajmniej udostępniają coś w rodzaju strict mode, które można sobie włączyć. Jeżeli jakiś projekt tego nie robi, w mojej ocenie nie jest warty straty czasu.CopyConstructor/sklonowanie + jakaś metoda clear()? - nadal lepsza metoda, niż zmienne statyczne.Bez testów, bez jasno określonych zależności musimy uwierzyć Ci na słowo, że u Ciebie tak nie będzie. A ja już zauważyłem, że klasa View ma chyba zależność* do klasy Registry i stałej REG_MSG (patrz linia #89**).Tutaj szczerze powiedziawszy mam pewien problem, bo nie wiem czym do końca jest zaprezentowany kod. Na pewno nie jest to widok (jak rozumiem chodziło Ci o warstwę widoku w kontekście MVC i pochodnych?) bo widok to pojęcie znacznie szersze niż szablon (widok ? szablon). Nie jest to też typowy system szablonów. Biblioteka wspomagająca pisanie szablonów w PHP? Też nie do końca, bo wprowadza i wymusza już pewną architekturę do projektu, wprowadza elementy z szablonami niezwiązane. Nie wprowadza natomiast żadnych "helperów". Webowy framework? Też nie bo właściwie zajmuje się tylko szablonami. Sam napisałeś o tym "Będzie to taki mini pseudo MVC", ale mini pseudo MVC nie nadaje się do normalnego użycia*** - lepiej już skorzystać z pełnych frameworków.

* w dodatku, jak to zawsze określam, taka z dupy zależność, bo nijak nie da się jej podmienić. IoC FTW!
** jakbyś udostępnił jakieś repozytorium to mógłbym podlinkować do konkretnego pliku, konkretnej linii z konkretnej rewizji - ktoś kto odwiedzi ten wątek za tydzień, gdy już to poprawisz mógłby przynajmniej spojrzeć co było nie tak.
*** pomijam tutaj Ciebie, bo pisałeś to na własny użytek, pod własne projekty - tam mogło to spisywać się rewelacyjnie.

Ok, masz rację. Dorobię opcję czy ktoś chce wyjatki czy nie

No cóż, to tylko przeoczenie z mojej strony. Jak pisałem czyściłem tę klasę z mojego systemu i zapomniałem wywalić tę jedną linijkę. Dzięki za znalezisko


Klasa View to jest klasa, która zastępuje system szablonów, np. Smarty. Temu chyba nie zaprzeczysz? Niczym więcej to ma nie być. ten mini pseudo MVC co jest wpaczce wymyśliłem i napisałem w 15 minut tylko poto by pokazać przykładowe użycie klasy View. No w coś ją musiałem wsadzić by pokazać jak jej używać
Moim głównym celem było pokazanie, głównie dla początkujących, którzy latają po forach z coraz to dziwniejszymi pytaniami: a jak to zrobić w smarty, a jak zrobić działanie w smarty, a jak...... i tak bez końca. Im smarty nie jest do niczego potrzebne. Kupie innych osób też nie i to chciałem właśnie pokazać.
Jak pisałem sam tego używam w dużych projektach i to się naprawdę sprawdza. Po wielu latach spędzonych na smartym, oraz poprawkach czyichś kodów, gdzie mieli własne systemy szablonów, powiedziałem sobie: dość - nigdy więcej żadnego systemu szablonów!

edit:
Dyskusja z Tobą to czysta przyjemność Tak, masz rację, tak zrobię.

Smarty zyskało na popularności czy mnie znowu coś minęło? Jednak nie dziwię Ci się, że po doświadczeniach z tym czymś oraz "własnymi systemami" żywisz niechęć do szablonów.

IMO jeżeli chciałeś zademonstrować przykład użycia dużo lepiej byłoby, gdybyś zrobił to w połączeniu z jakimś FW:
1. Nawet początkujący zaczynają wyrastać z masochizmu jakim jest pisanie w czystym PHP, więc istnieje realna szansa, że ktoś faktycznie z tego skorzysta.
2. Wtedy będzie to faktycznie mogło stanowić realną alternatywę.
3. Od razu zobaczysz czy interfejs Twojej biblioteki jest zrypany czy nie. Jeżeli integracja będzie jednym wielkim bólem czterech liter, wiedz że coś masz masz spieprzone. Chociaż patrząc po źródłach/rozwiązaniach z niektórych popularnych PHP-owych FW, istnieje też opcja, że wina nie będzie po Twojej stronie.

Tu skolei ja nie jestem masochistą

edit:
parę poprawek
http://nospor.pl/klasa-widoku-poprawki.html

OK, bardzo mi sie spodobala ta klasa i chcialbym ja wykorzystac ,jednak mam problem z dodaniem polaczenia w bazie.
zrobilem sobie klase db :

[PHP] pobierz, plaintext 
class Db {
 
	protected $pdo;
 
		public function __construct(){
		try {
            $this->pdo=new PDO('mysql:host=host;dbname=dbname', 'dbuser', 'password');
            $this->pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        catch(DBException $e) {
            echo 'The connect can not create: ' . $e->getMessage();
        }
	}
}
[PHP] pobierz, plaintext 

no i wpakowalem ja do glownego index.php :

[PHP] pobierz, plaintext 
//teraz tworzymy nasz widok
require_once('Nospor/View/View.php');
require_once('Nospor/View/Db.php');
require_once('Nospor/View/Plugin/Base.php');
$view = Nospor\View\View::CreateInstance();
$db = new Db();
[PHP] pobierz, plaintext 

i gdy chce cos wywolac w pliku akcji przez

[PHP] pobierz, plaintext 
<?php 
 
$query = $db->prepare("SELECT * FROM users");
$query->execute();
[PHP] pobierz, plaintext 

to dostaje blad Fatal error: Call to undefined method Db::prepare()

dlaczego ?

chcialem tez ustawic PDO w konstruktorze clasy View :

[PHP] pobierz, plaintext 
public function __construct(){
		try {
               $this->pdo=new PDO('mysql:host=host;dbname=dbname', 'dbuser', 'password');
            $this->pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        catch(DBException $e) {
            echo 'The connect can not create: ' . $e->getMessage();
        }
	}
[PHP] pobierz, plaintext 

jednak dostaje

[PHP] pobierz, plaintext 
Class 'Nospor\View\PDO' not found in
[PHP] pobierz, plaintext 

Poczytaj troszkę podstaw m.in. jak stosować namespace w PHP.
Odwołanie new PDO będzie szukać klasy w zależności od położenia. new \PDO.
Z drugim błędem var_dump($db);

Przeciez Twoja klasa DB nie ma metody Prepare. To obiekt PDO ma obiekt prepare a nie twoja zewnetrza klasa, ktora ma obiekt PDO w sobie