Postep prac nad nowa wersja Coyote'a

0

Watek dla zainteresowanych zmianami :)

A wiec jeszcze przed wakacjami dodalem pare nowych rozwiazan do serwisu, ktore mozna obejrzec tutaj

Ostatnio natchnelo mnie do kontynuowania prac nad projektem. Doszedlem jednak do wniosku, ze kod calego systemu jest nieco przestarzaly, malo skalowalny. Zaczelem myslec nad nowymi rozwiazaniami i napisalem nowe "jadro" systemu ;) na ktore sklada sie framework nad ktorym pracuje. Postanowilem wykorzystac mozliwosci PHP5 i wobec tego engine jest niemalze w calosci obiektowe. Mam nadzieje, ze rowniez czytelniejsze dla programisty.

Przede wszystkim oparte jest na bibliotekach/modulach, ktore wlaczamy. W configu aplikacji mozna ustalic jakie biblioteki beda wlaczane na starcie, czyli np.:

$autoload['library'] = array('config', 'input', 'error', 'lang', 'cache'); // itd...
$autoload['helper'] = array('url', 'form'); 

Helpery to jak zapewne wiadomo, dodatkowe pojedyncze funkcje ktore mozna wykorzystac w kodzie. Mozna pisac wlasne biblioteki i wlaczac je podczas dzialania programu jezeli beda potrzebne:

$core->load->library('foo'); 

Oczywiscie nadal bedzie funkcjonowac klasa template. Jezeli ktos ma ochote moze wykorzystywac ja do tworzenia szablonow.

Ja jednak oparlem nowy core o wzorzec MVC. Mamy wiec w katalogu z programem, katalogi:

  • template (widoki)
  • model (ew. modele)
  • controller (kontrolery)

Mam tez mechanizm routingu, dzieki ktoremu we frameworku mozemy ustalic szczegoly zadania. Np. dla 4programmers konfig moze wygladac tak:

$config['route'][] = array(
	'url'			=> 'login/:method',
	'class'			=> 'login',
	'method'		=> ':method',
	'dir'			=> 'ucp'
);

$config['route'][] = array(
	'url'			=> 'user/:id/:class/:method',
	'class'			=> ':class',
	'method'		=> ':method',
	'default'		=> 'index',
	'dir'			=> 'ucp'
);

$config['route'][] = array(
	'url'			=> '*',
	'class'			=> 'index',
	'method'		=> 'main'
);

Mowiac najprosciej - jezeli user wejdzie poprzez URL: http://4programmers.net/Login zostaje skierowany do kontrolera /controller/ucp/login.php:

class login
{
    public function main()
    { // funkcje logowania }
}

Jezeli user wchodzi poprzez http://4programmers.net/User/5656 - kierujemy do panelu usera. Wszystkie inne URL'e - np. 4programmers.net/Delphi/Gotowce kierowane sa do innego kontrolera, ktory odczytuje zawartosc artykulu.

Ok, ale mowilem o widokach. Ze mozna uzywac klasy template, ale testowalem po prostu z uzyciem zwyklych wstawek PHP:

<form action="" method="post">
Imie: <input type="text" name="name" value="<?= $core->validate->name; ?>" /><br/>
Wiek: <input type="text" name="age" value="<?= $core->validate->age; ?>" /><br/>
<input type="submit" name="submit" />
</form>

Natomiast w kontrolerze:

<?php

class login extends controller
{
	function main()
	{
		$this->load->library('validate');
		$this->load->helper('form');


		if ($this->input->post('submit'))
		{	

			$data = array(
												'name' => array(
																array('string', false, 5, 50),
																array('email')
																),
												'age' => array('num', false, 2, 10)
				);

			if ($error = $this->validate->post($data))
			{
				echo $this->validate->error();
			}
			else
			{
				echo 'Dobrze';
				exit;
			}
		}	

		$this->load->view('form');
	}
?>

To taki przyklad ;) Kontroler sprawdza tutaj czy dane w _POST sa prawidlowe (ladujemy biblioteke validator), czyli pole "name" musi byc stringiem o dlugosci 5-50 i dodatkowo prawidlowym adresem e-mail [diabel] Jezeli wszystko ok, wyswietlamy komunikat "Dobrze".

A czemu w kontrolerze jest takie cos:

value="<?= $core->validate->name; ?>" />

Jezeli uzytkownik zle wpisze swoj wiek, a dobrze imie, formularz zostanie przeladoawny, a jako value bedzie wpisana wartosc (zeby nie trzeba bylo drugi raz przepisywac ;)). Mam nadzieje, ze nowa wersja Coyote pozwoli szybko pisac kolejne moduly, tak aby przyspieszyc rozwoj.

Dlugie przez caly czas przy tym, zapewne troche potrwa zanim obecny kod przepisze pod nowe jadro. Wowczas umieszcze na serwer i ew. do CVS w osobnej galezi zeby nie kolidowalo z obecna wersja.

Myslalem rowniez nad implementacja jakiegos prostego ORM. Chodzi mi o proste operacje typu: "dodaj komentarz", "edytuj komentarz", "usun komentarz". Zeby nie trzeba bylo pisac zapytan za kazdym razem do tego.

0

Hmm, skoro już nowe jądro jest gotowe - może warto to przerzucić na ASP.NET? [green] (taki luźny wizerunek przyszłości..)

0

Jasne..
I potem szukać ze świeczką serwerów by to postawić.

0

hm.. biblioteki/validatory/builderfomularzy do zludzenia przypomina mi cos co sam ze 2-3 lata temu napisalem.. przy okazji sobei dorobilem cos a'la namespace'y oraz ladne crash-dumpy z podgladem stracktrace'a i argumentow poszczegolnych wywolan:)

ponizej dwa przyklady - maja prezentowac mechanizmy, nie maja oszalamiac:)

http://80.55.243.202:2003/valid.php
http://80.55.243.202:2003/valid.html - zrodlo valid.txt
http://80.55.243.202:2003/error.php - wywala blad poza strona
http://80.55.243.202:2003/error.html - zrodlo error.php

http://80.55.243.202:2003/include/SSI/Newsy/News.html - zrodlo klasy News
http://80.55.243.202:2003/include/SSI/Newsy/NaglowekNewsa.html - zrodlo klasy bazowej Newsa (przyklad rzucenia bledu)

namespace'y:

usingi rejestruja 'namespacey' w jakich nalezy szukac klas.
oczywiscie usingow moze byc dowolnie wiele

fizycznie wyglada to tak jak w javie:)

  • namespace to katalog ("pakiet"), tutaj: /include/SSI/Newsy
  • klasy sa wyszukiwane w plikach .phh
  • panuje zasada: jedna importowalna klasa per-plik (->java)
  • panuje zasada: nazwa pliku=nazwa tej klasy (->java)
  • klasy sa wyszukiwane po swoich nazwach we wskazanych katalogach, w dokadnie takiej kolejnosci jak podano usingi (tak, mozna miec N klas "NEWS". zostanie wzieta pierwsza trafiona.. plus czy minus? sporne..)
  • pliki /include/*.phh sa zawsze dostepne, bez zadnego using('')
  • zaden plik .phh nie jest ladowany bez wyraznej potrzeby, klasy sa ladowane tylko gdy sa potrzebne i gdy dana nie byla jeszcze zaladowana
  • bardzo latwo mozna zrobic auto-using pozwalajacy oznaczyc pewne katalogi z klasami jako zawsze widoczne

a co do wyskakujacych errorow z podgladem stosu i argumentow.. mialem taka wizje no i ja osiagnalem az wydaje mi sie ze zbyt brzydkim sposobem aby mozna to bylo dac na "produkcje": buforowanie calej strony+przetwarzanie+szukanie bledu+formatowanie+generowanie popup'a.. to buforowanie jest evil, bo trzeba czekac az cala strona sie wygeneruje.. ale na wersje testowa/developerska - jak znalazl. mi osobiscie taki podglad oszczedzil maase roboty i sledzenia :)

jakby wam sie ktorys z w/w dodatkow spodobal - chetnie udostepnie pod warunkiem waszego nienasmiewania sie z udostepnionego kodu i podzielenia sie uwagami jakby mozna je dalej usprawnic:)

ps. pardon za powolnosc strony, mam upload na laczu piekielnie niski, nie ma cacheowania itede dupereli - to byl moj testowy serw:)
ps2. oczywiscie nie porownuje "kurczaka" do 4p :) kurczak byl pisany na zaliczenie.. to chyba wszystko wyjasnia :)


ps3. powiedzialem A no to juz i B powiem.. te tam buildery/walidatory to nie mam sie co chwalic.. testy sa dubowane - i JS i drugi raz w PHP. jakby ktos chcial sie pobawic:
http://80.55.243.202:2003/ - aby moc cokolwiek edytowc: login test, pass test
http://80.55.243.202:2003/pages/admin/ssi/news/zmien.html - zrodlo edytora newsow [edycja/walidacja/zapis/anulowanie/refresh strony-parenta po skonczeniu]

jak widac po kodzie, praca nad "frameworkiem" przebiegala tuz przed deadlinem i w dodatku stanela w polowie - masa rzeczy jest we freestyle'u. ale mam nadzieje ze widac dosc przejrzysta strukture walidatorow [libFields/libJavaSc*] :)

0

off-top - nie ma to, jak czystosc j. polskiego, heh ;]

quetzalcoatl napisał(a)

hm.. biblioteki/validatory/builderfomularzy do zludzenia przypomina mi cos co sam ze 2-3 lata temu napisalem.. przy okazji sobei dorobilem cos a'la namespace'y oraz ladne crash-dumpy z podgladem stracktrace'a i argumentow poszczegolnych wywolan:)

0

ble:P moze sie myle, ale napisanie tego samego w czystym polskim zajelo by o 2-3 linijki wiecej i sprawilo wiecej zachodu w zrozumieniu co mam na mysli

0

Nie mam ochoty czytać tego wątku, pragnę jednak powiedzieć jedną rzecz: każdorazowe parsowanie tekstu przez php przy wyświetleniu stront zarzyna serwer, już w tej chwili load oscyluje około ~50%-70%. Jeśli dodane zostaną nowe funkcje a nie zostanie ZNACZĄCO odciążony procesor to trzeba bedzie chyba szukać czegoś z opteronem...
Wypróbowywałem lokalnie u siebie lokalnie keszowanie sparsowanych treści artykułów na dysku, dla długiego tekstu czas generowania strony zmalał z około 300milisekund do 6ms.

0

Yhm, rozumiem, ze chodzi tutaj prawdopodobnie o geshi i inne opcje parsowania artykulow? ok, trzeba bedzie pomyslec o cachu dla tekstow.

0

Nie wiem, aż tak dokładnie się profilerem nie bawilem :) W kazdym razie wywołanie parsowania tekstu pobranego z bazy danych zajmuje najwięcej czasu, przy dłuższych tekstach z masą odnośników itp. nawet 98%.

0

Rozumiem. Niestety modul parser.php jest dosc czasochlonny. Oczywiscie kolorowanie skladnii swoja droga, ale jest tam wiele skomplikowanych wyrazn regularnych, ktore odpowiednio spowalniaja generowanie strony.

0

Więc po prostu należy trzymać gdzieś WSZYSTKIE referencje ze strony i do strony i w razie zmian kasować cache wymagających przeparsowania stron.
W wersji jaką mam na dysku niestety pewne referencje typu obrazków lub [zdaje się] templatów nie miały w bazie zapisanych referencji co się do nich odnosi i w pewnych wypadkach wersja z cache była nieaktualna.

0

RegExp można będzie spróbować przejrzeć wszystkie - może da się coś zoptymalizować, ale nie sądzę, by to miało jakiś znaczny wpływ na całość.

0

Jesli chodzi o cachowanie to ja bym proponowal:
http://pl2.php.net/manual/pl/ref.memcache.php
diabelnie szybki i u nas mialby duze pole do popisu bo przeciez arty zmieniaja sie tylko pojedyncze wiec wiekszosc spokojnie by mogla z cache wychodzic :)

Osobiscie nie pisalbym frameworka pod coyote bo funkcjonalnie nie bedzie sie pewnie roznic od zenda a bez sensu troche pisac cos co juz istneje (widzialem, widzialem, fajnie jest napisac cos takiego swojego) :>

Nie mysleliscie jak podniesc troche poziom forum? Moze warto pomyslec o jakims rozbudowanym dziale dla freelancerow (samo subforum to imho malo) Przydaloby sie zachecic jakos ludzi ktorzy maja spora wiedze aby chcialo im sie odpowiadac na forum, wtedy pojawia sie ciekawsze watki i ogolny poziom serwisu powinien pojsc w gore :)

0
Pedros napisał(a)

Osobiscie nie pisalbym frameworka pod coyote bo funkcjonalnie nie bedzie sie pewnie roznic od zenda a bez sensu troche pisac cos co juz istneje (widzialem, widzialem, fajnie jest napisac cos takiego swojego) :>

Niektorzy ludzie maja podzielone opinie, czy jest to rzeczywiscie framework (bo slowo 'framework' ma w nazwie), czy zbior luzno powiazanych klas. Osobiscie nie widze niczego nadzwyczajnego w tych klasach...

Moze warto pomyslec o jakims rozbudowanym dziale dla freelancerow (samo subforum to imho malo) Przydaloby sie zachecic jakos ludzi ktorzy maja spora wiedze aby chcialo im sie odpowiadac na forum, wtedy pojawia sie ciekawsze watki i ogolny poziom serwisu powinien pojsc w gore :)

hmm... jezeli chodzi o osobny dzial to planowany (chyba od 2 lat :D) jest dzial "Praca". Hmmm... jaki dzial masz na mysli? I jaki pomysl na zachecenie?

0

Ja bym proponował 2 wersje skryptu, nie warto zaczynać też drugiego nie kończąc pierwszego :D

1 użytkowników online, w tym zalogowanych: 0, gości: 1