(better) Code practices - Issue #2

In urma WORST CODE PRACTICES m-am gandit ca ar fi bine sa existe si un "better" ca sa nu ne aratam doar fata negativa

Cel mai rudimentar template engine

<?php
class Template {
	var $vars = array();
	public function set($res,$val=NULL) {
		try {
			if(is_array($res)) {
				$this->vars = array_merge_recursive($this->vars,$res);
			}
			elseif(is_string($res)) {
				if(!is_string($val)) {
					throw new Exception('$val is not string');
				}
				$this->vars[$res] = $val;
			}
			else {
				throw new Exception('Unknown $res type');
			}
		}
		catch(Exception $e) {
			if(class_exists('FirePHP',FALSE)) {
				$fb = FirePHP::getInstance(TRUE);
				$fb->fb($e);
			}
			else {
				echo 'Caught Exception in "'.$e->getFile().'" on line '.$e->getLine().': "'.$e->getMessage().'"<br />';
			}
		}
	}
	
	public function render($tplfile) {
		try {
			if(!file_exists($tplfile)) {
				throw new Exception('Template file "'.$tplfile.'" does not exist');
			}
			if(!is_readable($tplfile)) {
				throw new Exception('Template file "'.$tplfile.'" is not readable');
			}
			foreach($this->vars as $k => $v) {
				$$k = $v;
			}
			include($tplfile);
		}
		catch(Exception $e) {
			if(class_exists('FirePHP',FALSE)) {
				$fb = FirePHP::getInstance(TRUE);
				$fb->fb($e);
			}
			else {
				echo 'Caught Exception in "'.$e->getFile().'" on line '.$e->getLine().': "'.$e->getMessage().'"<br />';
			}
		}
	}
}
?>

Utilizare:

$t = new Template();
$t->set('title','Hello world');
$t->render('foo.tpl');

unde foo.tpl contine

<title><?php echo $title;?></title>

Bineinteles poate fi extins sa recunoasca si alte tipuri de date in set().

A. Avantaje:

1. Rapid
2. Cacheable (zend opcode cachers)
3. Flexibil
4. Fun
5. Profit

B. Dezavantaje

1. siguranta minima

Dezavantajul 1. nu ar trebui sa fie un impediment daca template-urile sunt de incredere/verificate in prealabil (ceea ce este cazul de multe ori). In schimb, este rapid, nu are dependente, flexibil - pentru ca poti accesa orice doresti din template cu cuvantul cheie global , etc.

Pt incepatori: pentru asa ceva este utila cunoasterea scopului variabilelor, variabile variabile.

C. Q:

1. Deci de ce Smarty sau alte chestii pe care trebuie sa stai sa le inveti cu lunile ca sa le folosesti la puterea lor maxima, cand poti folosi asa ceva, home-made?
2. Ati/Veti folosi asa ceva in proiectele voastre?

D. Astept

1.comentarii
2. adaugiri, si mai ales,
3. puteti posta si voi threaduri cu titlul "BETTER/WORST CODE PRACTICES" cu propriile idei. Voi incerca sa le strang la un loc.

Edited by OriginalCopy, 29 April 2008 - 14:53.

Părerea mea: PHP în sine este un "template system", acuma dacă i se pare cuiva că e mai de folos un Smarty, fiecare cu păsărica lui.
Clasa de mai sus arată...drăguț și cam atât. Se poate "traduce" ușor în:

$title = 'Hello world';
include('foo.tpl'); //cu handler-ul setat corect din Apache

De ce să mai adaugi un layer? Există o tendință de a duce abstractizarea la extrem încât un cod ce s-ar scrie simplu în 2-3 linii va arăta ca naiba în 20 de linii (ok, nu e cazul codului de mai sus, dar este posibil, credeți-mă)...

Totuși până la urmă, depinde de stilul pe care fiecare vrea să-l adopte și care i se pare mai rapid, mai eficient, care se transcrie în cod mai ușor de întreținut sau doar pentru a fi "diferit"

Eu prefer asa pentru ca:
1. oricat de complexa ar deveni "aplicatia", pot vedea concret ce am in template si ce nu
2. nu poluez namespace-ul
3. error checking in jurul template-ului. Ar putea fi extins cu set_error_handler() s.a.m.d.
4. asa separ si izolez "business logic" de "view". da, MVC e cool. da, MVC nu se potriveste arhitecturii web.

Sunt acele mici detalii care fac diferenta, consider eu.

 OriginalCopy, on Apr 29 2008, 16:28, said:

Se potriveste foarte bine, daca se face un efort in sensul asta (de ex. http://www.castlepro...rail/index.html sau  http://asp.net/mvc/) si se renunta (macar partial) la obsesia pentru "scriptlets" care au fost foarte populare printre programatorii de ASP sau PHP la inceputuri...
Si in PHP s-au dezvoltat chestii similare ( http://www.phpmvc.net/ sau http://www.mustap.co...-mvc-frameworks)

Struts e un framework pentru web care foloseste modelul MVC. Mie personal mi se pare o complicatie inutila tinand cont ca incearca sa simuleze modelul de programare desktop pe web.

Revenind la intrebarile tale:

Quote

Am instalat smarty pentru prima oara acum cateva zile. Nu mi s-a parut complicat si mi-a luat fix 5 minute sa inteleg cum functioneaza. Inca doua ore ca sa citesc manualul cu cele mai importante functii si probabil in cateva zile programam in Smarty cu ochii inchisi. Intrebarea ta ma face sa cred ca nu te-ai uitat pe Smarty pentru ca are tot ce scrii tu acolo si ceva mai mult

Quote

Smarty n-am folosit. Cand programam in PHP nu exista Smarty asa ca aveam "un fel" de framework asemanator. Zic asemanator pentru ca era gandit putin diferit dar scopul era acelasi .. separarea codului php de html, rapid development si reutilizarea aplicatiilor si codului deja scris. Intre timp am trecut pe Java si am luat si framework-ul cu noi cu avantajele specifice tehnologiei (modulare, independenta de baza de date etc).

Iar apropo de template engines .. daca site-urile pe care le dezvolti cu el sunt simple e ok .. daca insa site-urile sunt mari si cu multe aplicatii la un moment dat se ajunge ca limbajul template-ului devine atat de complicat incat e nevoie de programatori sa scrie (pseudo)codul html lucru care deja contrazice scopul initial Cred ca singurul template engine care rezolva aceasta problema era Enhydra/XMLC avand insa "dezavantajul" ca trebuie sa compui intai pagina HTML dupa care sa faci programarea

Edited by urban, 29 April 2008 - 20:25.

Quote

Intr-adevar, nu am folosit smarty intens, dar m-am uitat prin sursa lui. Nici nu discutam despre faptul ca nu se poate face ceva in smarty, ci despre overhead. Care e pretul lui smarty?. In PHP "simplu" se pot face templates cu overhead minim, iar "full-blown template engines" nu au avantaje cu adevarat decisive fata de acesta

Quote

de acord

Quote

scopul acesta fiind separarea logicii/operatiilor/transactiilor de afisare (nu la asta te refereai?)

Edited by OriginalCopy, 29 April 2008 - 21:16.

Iara discutii religioase (similare cu 'language-wars') dar pe teme mai 'abstracte', gen "MVC nu e/ba e pentru web" ?

MVC pe web: simplu. MODEL -> b.d. si ce-i in ea (date/obiecte business/cum vreti voi sa le ziceti), VIEW -> HTML-ul paginii, CONTROLLER -> fisierul php.

Dragut template "engine", dar chiar nu ofera nici un avantaj doar un layer in plus de abstractizare... Daca tot introduci inca un layer, atunci sa iasa si ceva bun din asta. De exemplu, template inheritance e un gizmo interesant, tocmai am implementat sistemul de-l are django in php si folosit live la un site si sunt foarte multumit de puterea care se pare sa o dea inheritance (chit ca nu am implementat si multiple inheritance).

Totusi, un designer de html nu va intelege asa usor <?php echo $title; ?> dar va intelege foarte bine <div> {CONTENT} </div> deci recomand un engine de template-uri care 'compileaza' (adica transforma <div>{CONTENT}</div> in <div><?php echo $CONTENT; ?></div> si dupa aia la display() face include la fisierul 'compilat'). Am scris deja 2 engine-uri de-astea, unu il folosesc la un site cu 5 milioane (!) vizitatori pe zi si .. It IS worth it. Si MVC merita. Cu conditia sa stii sa pastrezi simplitatea (care in domeniul web de multe ori inseamna 'viteza') componentelor.

Problema cu MVC-ul este ca baga in aceeasi oala datele si logica (culmea e ca pe web rareori se intampla sa fie asa) in timp ce are o componenta cam inutila pe partea de web - Controller-ul. Si asta pentru ca isi trage radacinile din programarea desktop unde controller-ul este o componenta importanta iar datele de cele mai multe ori sunt tinute in fisiere de configurare sau in registri sau in cel mai bun caz in embedded db.
Mie unul pentru web mi se pare mai naturala abordarea clasica 3 tier - Presentation + Business logic + Data. Daca intre date si business logic exista deja cateva framework-uri de abstractizare (eg. EJB) intre business logic si presentation lucrurile sunt cam confuze.

Revenind la PHP lucrurile sunt si mai incurcate .. cred ca am si scris pe celalalt topic cu "worst code practices" ca in PHP diferentierea intre tiers exista doar in mintea programatorului pentru ca in final un fisier PHP contine in el si HTML si business logic si SQL deci numai 3 tiers nu e si sa incerci sa le desparti doar de dragul de a avea un model va duce la o complicare inutila a intregului framework precum si la o performanta mai slaba decat standardul cod php

Ma bucur ca a adus cobru vorba de "template inheritance" asta fiind unul din motivele pentru care nu-mi place smarty. Am sa incerc sa explic pentru cei care nu stiu despre ce este vorba:
In Smarty fiecare pagina este construita folosind un fisier template. Acest fisier template contine html, instructiuni ale template-ului sau alte template-uri incluse (cam in acelasi fel in care se includ si fisierele PHP standard). La site-uri cu cateva zeci de pagini este ok insa in momentul in care site-ul devine complex fiecare noua pagina trebuie "construita" de la 0 chiar daca exista deja elemente de template care compun pagina. Pur si simplu fiecare pagina se construieste din nou.

In modelele care folosesc template inheritance s-a plecat de la ideea ca site-ul are un layout consistent care pleaca de la ceva generic si in functie de fiecare pagina se ajunge la ceva specific. Se pleaca de la o pagina cat mai abstracta care se extinde (exact cum se extind obiectele in OOP) cu metode specifice pana se ajunge la constructia unei pagini propriu-zise. Avantajul este ca pe masura ce site-ul se complica devine mult mai usor sa dezvolti pagini noi .. pur si simplu gasesti una cu un layout cat mai apropiat de ceea ce ai nevoie si rescri doar bucatile din pagina care te difera (faci overwrite la codul respectiv). Dezavantajul in acest caz este ca ai nevoie de o planificare buna inainte sa te apuci de constructia site-ului pentru ca o proasta definire a paginilor abstracte initiale va duce la probleme complicate pe masura ce site-ul se dezvolata. De aceea acest model nu prea este recomandat site-urile de mici dimensiuni administrate de diverse persoane care nu cunosc sistemul.

Cel de-al doilea motiv pentru care nu-mi place Smarty si majoritatea template engine-urilor este ca in final cel care face HTML-ul trebuie sa invete (mai mult sau mai putin) template language-ul pentru ca la site-uri complicate este imposibil sa nu ai nevoie de for/while sau de un if. Majoritatea art directorilor pe care i-am cunoscut (asta insemnand 99% din ei) lucrau in Photoshop sau cel mult dreamweaver si nu vroiau sa stie de PHP, JSP/Java, ASP sau orice altceva are legatura cu programarea. Daca va uitati putin pe Enhydra XMLC o sa vedeti ca acolo se foloseste o metoda foarte ingenioasa si am sa-mi permit sa fac un copy paste de la ei de pe site ca sa intelegeti mai bine:

Quote

Dupa cum vedeti in acest caz fisierul HTML ramane curat (fara cod non HTML) ba mai mult decat atat poate fi "umplut" cu date dumb direct din faza de design (date care vor fi rescrise de catre programator) ca sa vezi cum vor arata cu paginile cu continut generat permitand realizarea unui protosite prezentabil clientului inainte sa te apuci de programarea propriu-zisa.

Din pacate insa nu cunosc nici un "template engine" care sa rezolve ambele probleme in acelasi timp.

Edited by urban, 01 May 2008 - 01:40.

 urban, on May 1 2008, 01:32, said:

Cred ca faci o confuzie... Nu zice nimeni ca daca aplici MVC trebuie sa bagi in aceeasi oala datele si logica (wikipedia sustine: "MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model."), ba din contra, CUM iti implementezi tu "modelul" (date + logica) si cate layere are "modelul" e doar problema ta, nu ti se impune nimic.
Controller-ul pe web, dupa cum am mai zis, este chiar pagina PHP, deci isi are foarte bine rostul!
Din nou citez wiki:
"Controller -    Processes and responds to events, typically user actions, and may invoke changes on the model."
Event in contextul web-ului este un "GET", un "POST", un "PUT", etc. Si astea rezulta din user actions (evident).
Si ca sa inchei tot din wikipedia:

Quote

Ce te face sa crezi ca fac o confuzie? Aici nu discutam despre cat de bun sau prost e MVC-ul in general ci cat de bine sau prost este implementat MVC-ul pe web.

Pur si simplu mi se pare stupid ca se incearca o implementare de MVC peste o implementare deja existenta: serverul de web e controller-ul, html-ul e prezentarea si php-ul/java e modelul. In acest caz ce rost mai are sa mai implementez inca un model MVC in model? Doar de dragul de a face framework-uri pe care nimeni nu le mai intelege? Vezi cazul struts care daca nu avea suportul IDE-urilor si al programatorilor veniti de pe desktop catre web probabil ca murea inainte de a se naste. Poate de cand cu Ajax-ul lucrurile sa se schimbe putin dar asta tot nu justifica un model MVC in Java/PHP (cel putin pana cand nu se schimba fundatia - HTTP-ul).

Ceea ce am zis mai sus este parerea mea personala despre MVC on web si din pacate nimic nu ma poate convinge ca modelul nu este altceva decat o simulare nefericita a programarii desktop pe web. Si zic asta dupa ce am lucrat intr-un proiect cu struts care avea nu mai putin de 6000 de intrari in controller .. carora le corespundeau 3000 de fisiere jsp respectiv 3000 de EJB-uri