phiend2: reaktywacja Opcje

[chmolu]

Hawk: Phiend to naprawdę świetny kawałek kodu, dobrze zaprojektowany, ładnie napisany, ale... przekombinowany. Uważam, że dla php to za duży balast.

Dla mnie Phiend2 jest typowym przykładem frameworka, nad którym pracuje się latami, co chwila poprawiając jakiś kawałeczek, żeby ładniej wyglądało. IMO to się mija z celem. Pierwsza wersja Phienda była prosta i umożliwiała ci skupienie się na budowaniu aplikacji. Teraz zamiast skupić się na apikacji budujesz idealny framework.

Kod php udostępniony na użytek publiczny nigdy nie zostanie wykorzystany przez ludzi w całości. Każdy woli napisać coś swojego. Przykładem jest mnogość systemów szablonów, driverów do baz danych, czy frameworków. Zgadzam się w 100%, w php pojęcie 'reusable' chyba nie istnieje. Choć przyznam, że osobiście też wolę w php napisać wszystko samemu, gdy widzę jaki śmietnik jest w danej bibliotece. Dlatego coraz poważniej rozważam dokładniejsze poznanie Ruby'ego, albo Javy.

Jak tylko napisałeś ten temat i ochoczo zgłaszali się pierwsi do pomocy wiedziałem, że nic z tego nie będzie. Jeśli masz wizję, wszystko zaprojektowałeś i napisałeś od początku to lepiej będzie, gdy nadal sam będziesz się tym zajmował. Naprawdę trudno znaleźć w takim wypadku ludzi, którzy zrealizują tylko twoją ideę. Dlatego nie proszę nikogo o dołączenie się do prac nad moim "wymarzonym" skryptem. Nawet jeśli ktoś się zgłosi, to nie chcę później poprawiać każdej linii kodu napisanej przez inną osobę. Wiem, że nikt nie zrobi tego zgodnie moją wizją.

Inną sprawą jest, gdy projekt od początku jest tworzony przez grupę ludzi, którzy wspólnie ustalają założenia i piszą kod. Tutaj zazwyczaj udaje się dojść do porozumień co do stylu kodowania, projektu i samego kodu.

[matid]

A co do innych zastrzeżeń:

phiend.context
Przy tworzeniu instancji klasy BasicHttpRequest usuwane są wszystkie tablice zawierające zmienne superglobalne ($_GET, $_POST, $_COOKIE, itd.).
Klasa BasicHttpSession jako argument do konstruktora wymaga klas implementujących interface IHttpRequest i IHttpResponse, czyli np. BasicHttpRequest i BasicHttpResponse. Teraz przejdźmy do sedna sprawy.
Chodzi o metodę BasicHttpSession::start(), która wywoluje funkcję session_start(). Tylko pojawia się problem - ta funkcja będzie za każdym razem tworzyla nową sesję, bo nie może znaleść Id poprzedniej sesji (tablice superglobalne są usunięte). Więc przez session_start() brakuje takiego kawalka kodu:

[PHP] pobierz, plaintext 
<?php
if( $this->getMethod() != 0 )
{
	session_id( $this->request->getParameter( $this->getName(), $this->getMethod() ) );
}
?>
[PHP] pobierz, plaintext 

[squid]

wg mnie nie jest tak zle

Oczywiscie ze nie wszystko jest pieknie i rozowo ale tak jest zawsze, zeby framework byl czms wiecej niz przelotnym pomyslem jednej osoby trzeba pracujacej grupy a nie jednej osoby bo ona (ta osoba) narzuca swoje rozwiazania nie widza problemu z innych perspektyw, to jest ANTI-REUSEABLE. Moze i nie monza zbudowac takiego kodu w php ale moze warto by sie skupic nad samamym szkieletem frameworka (wiem ze to gluio brzmi). Chyba kazy kto przegladal zrodelka chcialby dodac cos od siebi, uzyc czegos innego itd. Moze wiec wypracowac jakies wspolne API i jak ma to wszystko dzialac aby bylo maksymalnie elastycznie. Idea budowania aplikacji z klockow bardzo mi sie podoba ale bez szkieletu klocki sie posklejaja. Interfejsy mysle ze tu duzo daja ale to za malo. Mysle ze dobrze byloby zrobic taka wyliczanke, podzielic wszystkie zadania na fragmenty i napisac taka klasa ma takie wlasciwosci i metody, takie argumenty (zgodnie z idea programowania defensywnego sprawdzac czy all jest ok) i na tej podstawie zaczac pisac bo bedzie to o wiele leastyczniejsze kiedy bedziemy wiedziec czym ma sie dany kawalek kodu zajac a to jak to sie zaimplementuje to rzecz gustu.

[hawk]

Uff! Ale przynajmniej coś się ruszyło w temacie .

@chmolu: Masz sporo racji. Zwłaszcza, jeżeli pamiętać, jak skończył THOT. A przecież gdyby nie THOT, nie ruszyłbym phiend2.
Niestety, doba nie jest z gumy, a ja już mam doświadczenia z phiend1 i wiem, że nie będzie mi się chciało znowu robić strony, pisać dokumentacji, odpowiadać na maile użytkowników, itd, itd. Ja się nadaję na projektanta. Na kodera już mniej, a na testera i support w ogóle. Odechciewa mi się . Zresztą, ja nawet nie zajmuję się zawodowo php, więc robię to tylko dla przyjemności.

@NULL:

Czemu - może jest lepszy ? Potrzebna matką wynalzku - gdyby wszyscy myśleli jak Ty ( @Hawk )to Jargon i Creole by nie powstały bo jest AdoDB
...
A to phiend jest super spójny i idealny  Wszystko w nim pasuje do siebie  A mi coś w tym kodzie co napisałeś może nie pasować bo nie jestem Tobą...

Problem z Mojavi polega na tym, że to jest framework MVC, a nie driver do bazy danych. Nie mam nic przeciwko Creole (tego drugiego nie znam) - robi konkretną rzecz, możesz wybrać pomiędzy różnymi bibliotekami. Ale nie ma żadnego powodu, dla którego wybierając framework MVC musisz się dodatkowo przebijać przez ich warstwę do DB - to są nie związane ze sobą rzeczy. Gdyby twórcy Mojavi wypuścili osobno bibliotekę do DB, nie byłoby problemu.
A phiend2 pewnie wcale nie jest spójny i idealny. Raz, że on nawet nie do końca na razie działa. Dwa, że ideału nie ma. I ja nie twierdzę, że jest super. Jak Ci się nie podoba, to nie mam pretensji. Jak Ci się częściowo podoba, a częściowo zrobiłbyś coś inaczej, to daj znać - może Twój pomysł jest lepszy i będziesz miał to co chcesz w kodzie phienda?

@matid: Przyznaję się bez bicia, że phiend.context nie jest jeszcze sprawny. Słuszna uwaga.

CDN.

[aleksander]

Intercepting Filter (w postaci dekoratora na każdą akcję i w stylu javovym na cały request)

Zrobiłem właśnie taki IF, jeżeli chcesz hawk, prześlę Ci go, obejrzysz i może włączysz do projektu:)

pozdrawiam

--
UPDATE: BasicHttpSession już tez właściwie działa.
hawk: po co metoda Session::getMethod()? Ona w ogólne jest nieużywana.
Dodałem do klasy BasicHttpSession interfejs ArrayAccess więc można robic $oSession['bla'] :]

Widze jednak ze nikt sie juz phiendem nie interere nie to nie:P

Ten post edytował aleksander 29.07.2005, 02:06:50

[Neotion]

moge się dołączyć jako dokumentator i torche moge kodu napisać albo poprawić ale raczej wolałbym cos na prace w domciu bez neta bo nie mam stałki ale tutoriale mógłbym napisać pozatym mógłbym się tym w szkole pochwalić - ide do technikum informatycznego

[matid]

UPDATE: BasicHttpSession już tez właściwie działa.

Jak rozwiązałeś problem tworzenia nowej sesji przy usuniętych $_COOKIE?

[aleksander]

UPDATE: BasicHttpSession już tez właściwie działa.

Jak rozwiązałeś problem tworzenia nowej sesji przy usuniętych $_COOKIE?

yyyyy ... to przynajmniej juz wiem po co przekazywane było do konstruktora HttpRequest...

BTW nie wierze, że temat odżył

[matid]

yyyyy ... to przynajmniej juz wiem po co przekazywane było do konstruktora HttpRequest...

BTW nie wierze, że temat odżył

Już o tym pisałem tutaj. Nie wiem, czy znajdziesz inne rozwiązanie i czy w ogóle warto, ale moje wydaje się działać.

Ten post edytował matid 5.08.2005, 18:41:53

[aleksander]

ja pomyslalem o czym takim:

[PHP] pobierz, plaintext 
<?php
$oHttpRequest = new BasicHttpRequest();
 
$oHttpContext( $oHttpRequest, new BasicHttpContext, new BasicHttpSession( $oHttpRequest ) );
?>
[PHP] pobierz, plaintext 

chodzi o to, zeby do HContext i HSessionprzekazac referencje do tego samego obiektu. A HSession p[otem wyciaga z cookie sessionid:)

[squid]

[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??

[hawk]

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 .

[aleksander]

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 

?

Ten post edytował aleksander 3.09.2005, 22:46:03

[Strzałek]

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

Ten post edytował Strzałek 11.09.2005, 07:37:47

[bela]

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 ;]

[hwao]

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

[aleksander]

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.

[anas]

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

[aleksander]

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

[hawk]

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.