Eddy Dean schreef op zondag 26 juli 2009 @ 12:30:
[...]
Ik heb zelf ook een hekel aan PHP hoor, maak je maar geen zorgen.
YAGNI betekend dat je geen dingen moet maken die je niet nodig hebt, niet dat je alles wat je wel nodig hebt zelf moet bouwen. Als ik smarty gebruik omdat ik dan zelf geen functie hoef te schrijven die de rijen van een tabel om en om een andere kleur geef, is dat toch juist iets goeds, omdat het mij tijd scheelt. Dat ik een groot deel van smarty niet gebruik boeit niet, omdat het me ook niet in de weg zit. YAGNI houdt in dat je zelf geen template taal met alles er op en er aan moet gaan schrijven als je een groot deel niet nodig hebt.
Correct, maar mijn punt is meer dat PHP al een template taal __IS__. Het gebruik van Smarty is daarbij redundant: smarty is eigenlijk een preprocessor voor een preprocessor, en dat is imo 2x stom. Het doet me een beetje denken aan macro's in C/C++, die worden ook over 't algemeen al zo goed gebruikt vaak
, en zijn dan vooral leuk om te debuggen...not. Misschien is het dan ook een kneejerk reactie van me, want begrijp me niet verkeerd, macro's zijn soms gewoon onvermijdbaar voor de convenience, en datzelfde kan eventueel gezegd worden ook voor smarty, echter heb ik het nog daarbij niet kunnen inzien.
Ik ben het helemaal eens met DRY (Don't repeat yourself" maar ook met "Don't repeat others". (hoe zullen we dat noemen? DRO?). Smarty heeft een prima featureset om view-dingetjes te regelen, dus is dat wat mij betreft een goede keus.
Maar Smarty heeft ook een huge shitload aan dingen die je NIET nodig hebt en imo nadelig is als je het vergelijkt met wat PHP al doet. En dat is dus mijn punt van YAGNI. Het meeste is gewoon redundant aan PHP. Nu zeg je idd dat je dat niet hoeft te gebruiken, en correct, daar zou ik het normaliter mee eens zijn ware het niet dat smarty gewoon z'n eigen syntax introduceert en eigenlijk daarmee opaque is voor de developer. Als je eenmaal aan smarty begint heb je ook meteen een opaque dependency door die afwijkende syntax van hun. Een sane interface in PHP daarentegen had je gewoon eenvoudig in staat gesteld om een andere provider ervoor te gebruiken, wat dan ook een transparantere oplossing was geweest.
Zo'n "template engine" voor PHP hoeft wat mij betreft ook geen heel nieuwe syntax te hebben (wat smarty dus wel heeft), maar bestaat wat mij betreft uit een verzameling praktische functies die je werk uit handen nemen. Dingen als een BBCode parser, een wisselende-achtergrondkleur-in-tabel-dingetje, enzovoorts horen daar wat mij betreft ook bij. Dat een groot deel van de sites geen BBCode nodig heeft betekend toch niet dat die template engine dan niet geschikt is?
Het betekent imho dat je disproportioneel teveel erbij pakt dan dat je daadwerkelijk nodig hebt. Een BB code parser, daar bestaan duizend en een libraries al voor die in "native PHP" zijn geschreven. In rails kun je daar gewoon een plugin aan koppelen, punt is, het is allemaal gewoon Ruby wat je schrijft wanneer je het gebruikt, niet een eigen taal zoals smarty. Verder, die wisselende achtergrondkleur in tabellen, daar heeft Rails het principe van view helpers voor, en in het bijzonder hebben ze hier de cycle helper voor. Die kan je ook eenvoudig met de hand schrijven eigenlijk voor PHP en rechtvaardigt imo dan ook niet het includen van een frickin' PHP in PHP aka smarty.
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| <?php
class Cycler {
protected $range;
protected $size;
protected $current;
public function __construct($range = array()) {
$this->range = range;
$this->size = count($range);
}
public function next() {
$this->current = ($this->current++) % $this->size;
return $this->range[$this->current];
}
}
?> |
In je view kan je dan zoiets doen als:
code:
1
2
3
4
5
| <?php $cycler = new Cycler(array("odd", "even")); ?>
<?php foreach($rows as $row): ?>
<tr class="<?php $cycler->next(); ?>">
<?php endforeach; ?><!-- waarom niet gewoon end... volgens mij parser probleem :P --> |
Ik begrijp daarom ook echt niet waarom mensen iets log vinden zodra het meer functies heeft dan ze zelf nodig hebben. Dan gebruik je die functies toch gewoon niet? Boeien die paar kilobyte je echt?
Als die functies die je niet gebruikt je in de weg staan is het library gewoon slecht gemaakt.
Normaal gesproken zou ik het hier met je mee eens zijn, ware het niet dat de library die je gebruikt niet de core functionaliteit moet nadoen van de taal zelf. Dat is een laag aan redundantie die een dependency met zich meebrengt die onderhoud, ook met het oog op toekomstige versies, in de weg kan staan. Het is vaak niet eens zozeer een kwestie van size van het project (tenzij je met een linux project aan de haal gaat, want die doen over 't algemeen wel lastig mbt vendoring, niet alleen omwille van size maar ook omwille van security, het blijft altijd weer een extra stukje code dat je meeneemt wat een risico kan zijn). Maar ook hier kan het argument van size opgaan: aangezien PHP alles inlaadt bij een request en daarna ook alles weer dumpt wil je niet dat hij een freakin' template engine inlaadt om vervolgens maar 2 dingen ervan te gebruiken
Rails is ook geen lichtgewicht, maar die draait dan ook als applicatieserver en blijft zoveel mogelijk in memory: dat is meteen een voordeel en een nadeel afhankelijk van de situatie. Het pluspunt van PHP's "schaalbaarheid" is juist dat apps niet als applicatieserver draaien en in feite dus geen shared data hebben (excluding the database). Wil je dat voordeel helemaal leveragen, dan wil je niet dat hij teveel moet inladen voor elke request van disk, dat is dan wel duur.
Samengevat: Als het je tijd scheelt om een "template engine"/library met helper functies te gebruiken en je toch het zelfde resultaat behaalt: go for it, ook al gebruik je niet alle functionaliteit die dat library te bieden heeft.
Samengevat: ik vind dat PHP'ers eens zich goed achter de oren moeten krabben en zich afvragen waar ze die "template engine" nou echt voor gebruiken en zich dan eens af moeten gaan vragen of het wel echt die voordelen met zich meebrengt die het adverteert, vooral in het geval van smarty.
Een framework is iets heel anders dan een template engine, vergeet dat niet. Veel frameworks hebben ook zaken als ORM, authentication, authorisation, i18n, scaffolding (waar ik een absolute hekel aan heb. Ik zit niet de hele dag blogs en nieuwspaginas in elkaar te "programmeren"), een template engine, enzovoorts aan boord. Een template engine is dus veel "kleiner" dan een heel framework.
Een "template engine" is vaak een onderdeel van een framework idd, en het is daarom ook dat ik eens mensen zou willen aansporen om daar eens een kijkje naar te nemen en dan eens verlichting proberen te vinden in dingen die zij 200x ook programmeren, zij het waarschijnlijk een stuk slechter
Verwijderd schreef op zondag 26 juli 2009 @ 12:43:
De nadelen van echte frameworks vind ik dat de manier van templates er niet lekker in zit gebouwd. Je gaat je templates op een dusdanige manier gebruiken dat je framework optimaal is maar je templates er een beetje omheen gefrommeld zitten.
Kun je hier een concreet voorbeeld van geven?
Verder, in het kader van DRY, neem ook een kijkje naar m'n reacties in
Over logica en presentatie . ;-)
[
Voor 3% gewijzigd door
prototype op 26-07-2009 13:28
]
:strip_icc():strip_exif()/u/49396/icoon.jpg?f=community)
:strip_icc():strip_exif()/u/11014/27337_1472854245_8919_q.jpg?f=community)
. Je stopt alles in een of meerdere arrays/objecten, die je doorgeeft naar je view. Of je dat nu met smartytags of php tags merged met je html boeit weinig.
, zie ^^ :strip_icc():strip_exif()/u/55080/el-inigualable-chuck-norris_07.jpg?f=community)
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
:strip_icc():strip_exif()/u/51415/crop683ca4502b799_cropped.jpg?f=community)
/u/56791/e503ae2c4a3b9e802f74bac27efd412d.png?f=community)
:strip_exif()/u/53522/crop583d477015a24.gif?f=community)
:strip_exif()/u/47168/loop.gif?f=community)
:strip_icc():strip_exif()/u/141741/crop5dd6aa7923c3f_cropped.jpeg?f=community)
:strip_exif()/u/28900/sharingan.gif?f=community)
:strip_exif()/u/124530/youarehere.gif?f=community)