[PHP] pobierz, plaintext 
<?php
class XmlConfiguratorCompiler
 
	public function compiler($sPhpFile, $sXmlFile, $useSchema) {
		$dom = new DomDocument;
		$dom->load($sXmlName);
		if ($useSchema) {
			$dom->schemaValidate(PHIEND_MVC_DIR . '/schemas/XmlConfigurator.xsd');
		}
		$rootElement = $dom->documentElement;
 
		// PLUGINS
		$pluginsRoot = $this->findElement($rootElement, 1, 'plugins');
		foreach ($pluginsRoot->childNodes as $pluginNode) {
			if ($pluginNode->nodeType != 1) continue;
}
 
}
?>
[PHP] pobierz, plaintext 

wszystko cool tylko mamy linijke:

[PHP] pobierz, plaintext 
<?php
$dom->load($sXmlName);
?>
[PHP] pobierz, plaintext 

a w parametrach wejsciowych $sXmlFile i brak $sXmlName.
Czy to blad czy czegos nie zauwazylem??

Błąd, jak najbardziej błąd. A było to tak: dawno, dawno temu wszystko działało, hmm, standardowo. Tzn. mamy plik XML z configiem, framework sprawdza datę i jak trzeba, to generuje z tego php. Potem framework zaczął ewoluować, a kompilator XML za nim nie nadążał. Poza tym cała konfiguracja sprowadzała się do kilku pluginów i jednej metody addPlugin(). Więc kompilacja XML wyleciała na zewnątrz frameworka - pluginy można tworzyć i dodawać ręcznie, ale można mieć taki "Configurator", który doda te pluginy na podstawie pliku XML. Teoretycznie można mieć inny konfigurator, który będzie to wczytywał z pliku .ini, z nowego formatu Mojavi lub brał z księżyca.
A morał bajki jest taki, że XmlConfigurator generalnie nie działa, ponieważ nie jest potrzebny do działania frameworku.

PS. Dawno tu nie zaglądałem. Odezwę się, jak zdam wreszcie ten egzamin MCP .

czekamy hawk, czekamy...

UPDATED: swoja droga, gdy mamy HttpContext to jest problem przy uzywaniu Smarty, bo ono wywala wsio na ekran a my chcemy do Response->addContent(). nie da sie tego rozwiazac inaczej niz

[PHP] pobierz, plaintext 
<?php
ob_start();
$smarty->display();
$res->addContent( ob_get_clean() );
?>
[PHP] pobierz, plaintext 

?

Mogę sie oczywiście mylić, ale przecież można zrobić tak:

[PHP] pobierz, plaintext 
<?php
$res->addContent($smarty -> fetch('some_file.tpl');
?>
[PHP] pobierz, plaintext 

http://smarty.incutio.com/?page=SmartyFreq...tions#project-5

blad w HandleFactory

argument to $mClass, a w tresci metody mamy odwolania do $sClass

[edit]
hawk po co w configu przy pluginach dalej sciezke skoro to tylko autoloader powinien wiedzieć gdzie co jest? i w ogóle w kodzie widzę trochę requerow ;]

Hmm, mi sie po i wydaje ze include bylo by lepsze (skrypt "umiera" jak sie nie uda pliku zalaczyc - zakladam ze kazda zalancza klasa jest niezbeda do dzialania).

Co do sciezek to mysle ze sa one one potrzebne, czasme moze sie zdarzyc ze klasy nazywaja sie tak samo - wtedy autoloader nic nie poradzi.


Pozatym jak mamy podana jasno sciezke to autoloader nie musi sie odpalac, co pozwala zaoszczedzic czasu (przy duzej ilosci klas w mapie, napewno jest to wazne).

jest

[PHP] pobierz, plaintext 
<?php
class SimpleOutputBuffer implements IOutputBuffer {
	protected $aHeaders = array();
	protected $sContent = '';
 
	public function addHeader($sName, $sValue) {
		$aHeaders[$sName] = $sValue;
	}
?>
[PHP] pobierz, plaintext 

powinno byc

[PHP] pobierz, plaintext 
<?php
class SimpleOutputBuffer implements IOutputBuffer {
	protected $aHeaders = array();
	protected $sContent = '';
 
	public function addHeader($sName, $sValue) {
		$this->aHeaders[$sName] = $sValue;
	}
?>
[PHP] pobierz, plaintext 

pozdrawiam

UPDATE:

w klasie BasicPhpSession znalazlem jeden blad ale nie wiem czemu on wystepuje i czy czasem tylko u mnie wiec prosze to sprawdzic.

Metoda readSession() gdy jest unset($_SESSION); po refreshu ta zmienna jest pusta gdy tego nie ma, wszystko ok.

Hej.

Można gdzieś przejrzeć kod phiend'a v2? Bo udostępnione linki nie działają.
To co udało mi się prześledzić w wątku wydaje się interesujące, z tym że temat ucichł.

pozdrawiam

anas

prom Cie bardzo:)
www.alek.ltd.pl/phiend2.zip

Jak zapewne zauważyliście, długo mnie tutaj nie było i ten stan rzeczy nie ulegnie radykalnej zmianie. Po prostu przestało mnie to bawić. Programistą php nie jestem i nie będę, nie wiążę z tym przyszłości zawodowej, a w ramach spędzania wolnego czasu wolę wyżywać się na worku albo pić wódkę.

Projekt informatyczny, żeby był zauważony, musi żyć. Musi być aktywnie rozwijany. Trzeba reagować na zgłoszenia błędów i propozycje zmian. Trzeba robić ogólnie pojęty support. A tego akurat mi się całkowicie nie chce - w konkurencji spędzania wolnego czasu support plasuje się daleko, daleko za programowaniem. Natomiast bez supportu projekt staje się niszowy. Dla mnie niepotrzebny, bo ja i tak php w pracy używać nie będę.

Natomiast lubię projektować, i dlatego zostałem z rozgrzebanym kodem, który - sądząc po zainteresowaniu - jest dobrze pomyślany, ale którego sam nie doprowadzę do stanu używalności. Phiend2, jak pewnie zauważyliście, nie jest tak naprawdę frameworkiem. Jest zbiorem komponentów, na szczycie których jest co prawda framework MVC, ale nie jest on (dla mnie) najważniejszy. Teraz każdy ma własny framework, a ich porównywanie nie ma sensu. Natomiast mały komponent napisany w konkretnym celu może być znacznie łatwiej używany w różnych projektach.

Sytuacja jest więc taka: jest kilka mniej lub bardziej dokończonych komponentów i praktycznie martwa strona na SF. Na dole jest krótki opis tych komponentów. Jeżeli są zainteresowani, to chętnie przekażę je w dobre ręce, na zasadzie, że dalej jest to phiend, tylko autorów ma wielu. Na SF jest CVS, na którym można to rozwijać. Jest forum, jest cała infrastruktura. Alternatywnie można się przenieść. Kiedyś na tym forum krążył pomysł stworzenia własnego repozytorium dobrego kodu, ale chyba umarł.

Lista komponentów:
phiend.proxy
Pierwotnie nazywało się phiend.handle, ale słowo handler używane jest często i w różnych kontekstach, więc zmieniłem. Rozwinięcie klasy Handle obecnej w WACT, zapewnia lazy loading obiektów. Przekazuje się w kodzie proxy do obiektu, a samo stworzenie obiektu (łącznie z includowaniem pliku z kodem) odbywa się dopiero przy pierwszym użyciu. Kod ukończony, sa nawet unit testy (SimpleTest).

phiend.log
Zestaw klas do obsługi błędów. Inspirowany log4php, ale bez tego strasznego przerostu kodu. Z jednej strony bardzo obiektowy, co zapewnia elastyczne filtrowanie błędów i łatwe dodawanie nowych sposobów obsługi/zapisu błędów. Z drugiej strony najlepsza konsola prezentująca na ekranie informacje o błędzie, jaką do tej pory widziałem. Listing kodu wywalającego błąd i debug_backtrace to standard. Ale podawanie definicji każdej metody z tego backtrace, włącznie z miejscem definicji, nazwami i typem argumentów... mając do dyspozycji Reflection można dużo zrobić. Kod działa, ale na pewno można go dopracować, dopisać nowe handlery, poprawić wygląd konsoli, itd.

phiend.autoload
Prezentowany już tutaj na forum autoloader. Prosty, elastyczny, działający. Bardzo by się do niego przydał (jako osobny projekt) system do mergowania plików z kodem php, ponieważ sam mechanizm autoload w php jest czasochłonny. Ale być może coś takiego da się wykonać przy pomocy Phing...

phiend.auth
Prosty system uwierzytelniania oparty o zagnieżdżone grupy. Na tyle nieskomplikowany, że można go użyć wszędzie, i na tyle rozszerzalny, że można go oprzeć o dowolne źródło (DB, pliki ini, pliki passwd, LDAP, pliki Samby...) tworząc nowy handler. Zainspirowany Solarem i PEAR::Auth, ale znacznie mniejszy i łatwiejszy do dopasowania. Częściowo działa, ale kod jest niedopracowany i niedokończony.

phiend.context
Implementacja request, response i sesji. Temat znany, ale kontrowersyjny, ponieważ trudno ocenić jest obiektywnie, jaki sposób implementacji jest lepszy. Gdyby php miał w tym zakresie jakiś standard... W każdym razie uważam, że jakaś implementacja jest potrzebna, aby można było później rozwijać framework. Kod jest, ale nie jestem do niego przywiązany i z racji skomplikowania tematu nigdy nie byłbym z niego chyba zadowolony.

phiend.registry
Implementacja wzorca Registry. Do rejestru wrzuca się tzw. pluginy, a rejestr zapewnia dostęp do nich, lazy loading oraz prostą implementację Intercepting Filter. Prosty, działający kawałek kodu wydzielony kiedyś z MVC.

phiend.mvc
Framework MVC. Wykorzystuje większość z tego, co opisałem powyżej. Główne cechy:
- cała nie-corowa funkcjonalność wypchnięta do pluginów wrzuconych do rejestru
- przed i po akcjach wykonywane są filtry, implementujące wzorzec Intercepting Filter w postaci dekoratorów
- każda akcja ma konfigurację przekazywaną do filtrów
- akcje można dowolnie dzielić na moduły, a moduły zagnieżdżać w sobie, przy czym konfiguracja jest dziedziczna
- fragmenty corowej funkcjonalnośći również wypchnięte są do pluginów, żeby można było łatwo podmienić (np. router, odczyt konfiguracji dla akcji)
- źródło konfiguracji dla akcji teoretycznie dowolne, chociaż pozostaje implementacja plugina
Całość działała i przechodziła testy, ale potem zacząłem ostro przerabiać/optymalizować kod i skończyłem mniej więcej w połowie.

Na CVS są chyba jedynie pliki sprzed pół roku? Można by je zakutalizować?

Moim zdaniem przydałby się jakiś projekt w formie pisemnej. Mogę pomóc w jego napisaniu, ale z kodu go nie odtworze.

proponowałbym przeniesienie kodu pod patronat php.pl tak że my użytkownicy albo jakas ich część może nad nim pracować udoskonalać itp. coś w stylu linuksa gdzie każdy może dodac cos od siebie. co Wy na to?

Myśle, że jakakolwiek strona gdzie gromadzilibyśmy informację na temat projektu (w sensie całego przesiemwzięcia) byłaby bardzo pomocna. Na forum moża dyskutować, ale wyniki tych dyskusji powinny być zbierane w jakiejś zwiezłej i spójnej formie.

Czy to ma być organizowane pod patronatem php.pl to juz nie do mnie należy decyzja. Tak właściwie to nawet nie wiem co to znaczy, że phiend będzie tworzony pod patronatem php.pl.

chodzi mi o to żeby np hawk przekazał projekt jednej osobie ale nie pierwszej lepszej, i ta osoba zbierze jakąś ekipę która będzie miała prawa do grzebania w kodzie phienda.

ja osobiscie byłbym bardzo zainteresowany rozwijaniem phienda (niekoniecznie musze byc tym wymienionym rpzeze mnie wyzej;) )

ja sie zapoznaje z tym projektem:

jedno mi jest nie jasne, a mianowicie w BasicHttpRequest:

[PHP] pobierz, plaintext 
<?php
 
public function getMethod() {
	switch ($this->aServerVars['REQUEST_METHOD']) {
		case 'GET':  return self::GET;
		case 'POST': return self::POST;
		default:	 return null;
	}
}
 
?>
[PHP] pobierz, plaintext 

dlaczego tych stalych nie widze zadeklarowanych( chodzi mi o self::POST itp). Moze mi ktos to wyjascic

pingu, popatrz na interfejs IHttpRequest

hehe, no patrz nie sadzilem ze tak mozna Mi sie coraz bardziej ten proekt podoba analizuje dalej

Stuk, puk?

Czy projekt jeszcze żyje?

chyba nie, a szkoda...