Zelfde output, andere woorden
Wat gebruik je het best?
- echo of print?
- include of require?
en nog een hele lijst gevonden van aliassen: http://be2.php.net/manual/nl/aliases.php
include is niet hetzelfde als require. Als je include gebruikt en het bestand dat je include bestaat niet dan geeft hij een error maar voert de rest van de pagina nog wel uit. Bij require stopt hij het hele script en geeft hij alleen de error weer. Include gebruik je bij pagina;s waar het neit zo erg is als die op een of andere reden niet bereikbaar zijn. Require gebruik je bij bijv includes met database gegevens, want als die niet aanroepbaar zijn zal je hele website grotendeels neit werken, ervan uitgaande dat je met een database werkt.
Zodat je zoiets kunt doen:
Verder klopt het dat print een return value geeft en echo niet.
Quote:
Geen van beiden, gebruik een template engine. Maakt het bouwen, debuggen en onderhouden van een site een stuk eenvoudiger. Smarty is een bekend.Wat gebruik je het best?
- echo of print?
- echo of print?
Quote:
Zelf gebruik ik altijd require_once: een bestand wil ik slechts 1x gebruiken (de once) en er moet een fatal error optreden wanneer een bestand niet beschikbaar is. De error-handler stuurt dan een 404, pagina niet beschikbaar.- include of require?
De code die in een bestand staat, wil ik wellicht vaker gebruiken, maar daarvoor hoef je niet meerdere keren te includen. Vandaar dat _once zeer geschikt is.
pgFrank schreef op 17.08.2007 17:28:
Quote:
Geen van beiden, gebruik een template engine. Maakt het bouwen, debuggen en onderhouden van een site een stuk eenvoudiger. Smarty is een bekend.Wat gebruik je het best?
- echo of print?
- echo of print?
Hoe maakt een extra 'template engine' naast PHP een site bouwen en onderhouden makkelijker? (Ik ben nu wel eens benieuwd naar goeie pro-argumenten)
Daarnaast, welke van beide wordt dan door de template engine zelf gebruikt? :P
Quote:
- Scheiding van logica en output wordt keihard afgedwongen. Geen PHP in de templates, iedereen met html-kennis kan dus een nieuwe template maken.Hoe maakt een extra 'template engine' naast PHP een site bouwen en onderhouden makkelijker?
- Nooit meer gedonder met cookies en/of sessies, 'Headers already sent' heb ik al jaren niet meer voorbij zien komen, dat kan technisch gewoon niet voorkomen. html wordt op de laatste regel aangemaakt en geen regel eerder.
- Scheiding van werk: Het maken van de templates kan eenvoudig door een ander worden gedaan. Stel een lijst met namen op (onderdeel van de ontwerpfase) van de variabelen die nodig zijn en hoe de array's uitzien en klaar ben je.
- In een testbestand kun je alle variabelen en array's opnemen om al een werkend prototype te bouwen voordat de logica klaar is. Verwijder vervolgens langzaam maar zeker de data in het testbestand en je bent de logica (gedeeltelijk) en achterliggende database aan het testen.
- Het gebruik van een template-engine is dan wel extra code, maar geen extra werk. Sterker nog, het scheelt mij een hoop werk. En dat komt goed uit, ben liever lui dan moe.
- Wanneer ik geen html wil aanmaken, maar bv. een pdf, dan stop ik de aangemaakte variabelen in FPDF en ga dat parsen. Er zit mij dan geen html-zooi in de weg die in de logica wordt aangemaakt.
Quote:
Dat zal mij een rotzorg zijn, ik gebruik Smarty zoals die wordt aangeleverd door de community, test de versie met het systeem dat ik bouw en klaar is kees. Heb nog nooit de code doorgespit, zonde van de tijd...Daarnaast, welke van beide wordt dan door de template engine zelf gebruikt? :P
- Scheiding van logica: Dat heeft verder weinig met php binnen html te maken. Of je nu smarty-tags binnen html of php binnen html gebruikt, dat maakt geen verschil. Er zal altijd een beetje logica in templates moeten zitten nietwaar?
- Nooit meer gedonder met cookies & sessies: Dat heeft verder weinig met de 'template engine' te maken. Dat ligt er meer aan hoe je je programma opbouwt. Het voordeel van een template engine is dat hij dwingt om je code op te splitsen in verwerken & weergeven. Maar de keuze maken om een template engine te gebruiken of om je html & php in een apart bestand te zetten en dat bestand later te includen waneer je alles op orde hebt is 1 en dezelfde. De weg ernaar toe is wat anders. Template engines worden door beginners voor de eerste gebruikt omdat het 'stoer klinkt en iedereen het doet' en de 'include achteraf' kom je op doordat je al dan niet bewust gaat werken naar het MVC model bijvoorbeeld.
- Scheiding van het werk: Dat zou impliceren dat iemand die html kan ook de smary-syntax kent, maar niet naar PHP durft te kijken. Ik ken alleen situaties waarin 1 programmeur al het werk doet, of waarin de programmeur de html aangeleverd krijgt, en deze zelf stript van de dummytekst en voorziet van de nodige logica zoals lussen en if-else statements.
- In een testbestand kun je alle variabelen en array's opnemen: Of je nu een template engine of php zelf gebruikt, beiden kunnen dit. PHP heeft echter de mogelijkheid om gemakkelijk even var_dump en functies te gebruiken, terwijl dit in Smarty (als het goed is) lastiger is. Daarnaast vraag ik het me af of het handig is om vanuit die richting (van veel naar niets) werken handig is, maar dat is een ander verhaal en nu dus geen argument tegen.
- Het gebruik van een template-engine is geen extra werk. Sterker nog, het scheelt mij een hoop werk: Oja? Je moet de configuratie goed zetten (cache e.d. in het geval van Smarty) en je moet de documentatie doorspitten. Ook is het lastiger om functies en mogelijkheden toe te voegen. In PHP weet je hoe dit moet, je werkt er immers non-stop mee. Met Smarty zal je dit op een moment ook wel bereiken, maar dan heb je dus een 'taal' extra erbij geleerd. Sounds like meer werk to me.
- Wanneer ik geen html wil aanmaken, maar bv. een pdf, dan stop ik de aangemaakte variabelen in FPDF en ga dat parsen. Er zit mij dan geen html-zooi in de weg die in de logica wordt aangemaakt: Dat is geen 'template engine' argument, maar een argument om Model, View en Controller gescheiden te houden.
Enige argumenten voor de 'template engine' boven gewone PHP binnen je templates zijn dus? Tegen is de aparte syntax, de snelheid en de flexibiliteit/mogelijkheden.
Vandaar dat ik me nog altijd niet aan Smarty heb over gegeven.
Quote:
Klopt, maar de mindere PHP-goden verneuken templates door complete stukken logica, incl. database connecties!, in de template te zetten. Dat heeft niets, maar dan ook niets met presentatie-logica te maken. En dat is de logica waar jij op doelt en waar ik het ook volledig mee eens ben.of php binnen html gebruikt, dat maakt geen verschil.
Quote:
Diegene die het mij flikt om PHP in de template te zetten, wordt op staande voet ontslagen! En dan komt hij nog goed weg...Dat zou impliceren dat iemand die html kan ook de smary-syntax kent, maar niet naar PHP durft te kijken.
Quote:
Dat is eenmalig, zodra je dat onder de knie hebt, kun je dat bij ieder volgend project weer gebruiken. Iets nieuws leren is niets mis mee, zolang het maar voldoende rendement oplevert. Je moet de configuratie goed zetten (cache e.d. in het geval van Smarty) en je moet de documentatie doorspitten.
Quote:
Volledig mee eens en ik wist dat je zit zou gaan zeggen ;) Maar ook hier weer, de minder goden hebben het daar nog wel eens moeilijk mee. Heb me hier de vingers al eens vreselijk aan gebrand.Dat is geen 'template engine' argument, maar een argument om Model, View en Controller gescheiden te houden.
Quote:
Je moet roeien met de riemen die je hebt. Het niveau van de programmeurs is hier gewoon (een stuk) lager dan in NL. Wanneer ik nu een nieuwe programmeur moet aannamen, dan zal ik hem direct duidelijk maken dat hij als een zeehondje wordt doodgeknuppeld op het moment dat hij businesslogica in een template probeert te proppen. Die onzin heeft mij al veel te veel tijd, en dus geld, gekost.Enige argumenten voor de 'template engine' boven gewone PHP binnen je templates zijn dus?
Quote:
Gedeeltelijk mee eens, maar flexibiliteit (de kracht van PHP) is iets wat ik juist niet in mijn templates wil hebben. En mocht ik iets bijzonders nodig hebben, je kunt je eigen functies toevoegen aan Smarty. Dat is flexibel genoeg.Tegen is de aparte syntax, de snelheid en de flexibiliteit/mogelijkheden.
Wanneer je in je eentje aan een project werkt en alles van A tot Z zelf onder controle hebt, dan kun je prima uit de voeten zonder template-engine of een template-engine die ook PHP-code accepteerd. Ik heb daar ook mee gewerkt en met succes. Maar, zodra er meerdere mensen aan 1 project werken, is het vreselijk handig dat je tools hebt (in dit geval Smarty) die bepaalde zaken gewoon keihard afdwingen. Alleen een afspraak is dan niet genoeg.
Dan nog even wat anders:
Quote:
Hier worden opdrachtgevers gelukkig van, ik dus ook, er is namelijk al heel snel een werkend prototype beschikbaar. Hierdoor kun je samen met de opdrachtgever al heel snel het systeem doornemen en testen of dit het is wat hij in gedachten had. Ik ben nog niet tegengekomen dat er géén wijzigingen in een ontwerp nodig waren. En hoe eerder deze (nieuwe) eisen boven water komen, hoe beter.Daarnaast vraag ik het me af of het handig is om vanuit die richting (van veel naar niets) werken handig is, maar dat is een ander verhaal en nu dus geen argument tegen.
Testen begint niet nadat de code is opgeleverd, testen begint gelijktijdig met het ontwerpen! Betrek de opdrachtgever daar ook bij en presenteer resultaten waar hij wat mee kan. Een fraaie PHP-classe die voorraden weet te waarderen, leuk en aardig, maar dat is niet wat de opdrachtgever op het scherm ziet. Een testbestandje die je in de template stopt, is voor de opdrachtgever veel duidelijker en dit is ook vele malen sneller te realiseren.
X tijd later kun je dan alsnog de werkende versie tonen, maar dat zal voor de opdrachtgever niet heel anders zijn. 'het werkt', maar dat had hij ook verwacht/geeist.
my2cents
Ps. Er bestaat in dit soort discussies geen 'goed' of 'fout', alleen een 'wat bevalt mij het beste'.
pgFrank schreef op 17.08.2007 19:57:
Ps. Er bestaat in dit soort discussies geen 'goed' of 'fout', alleen een 'wat bevalt mij het beste'.
Gelukkig maar, kan ik tenminste niet beweren dat jij 'fout bezig bent' :P
Wat ik bedoelde met de 'verkeerde richting' was meer vanuit een usability-oogpunt en niet het doel uit het oog verliezen.
Als je groot begint is de drang om informatie op het beeldscherm te houden groot, en is de kans dat je dus features die in eerste instantie niet nodig waren, maar die vanuit dit oogpunt handig lijken erin sluipen groter. Op zich niet slecht, meer features, maar je raakt het oude idee kweit.
Er vanuit gaande dat het oude idee is opgesteld met papier, potlood, stikies en pijltjes :) Je kent ze wel: flowcharts, duidelijk afgebakende trajecten die de bezoeker moet doorlopen. Als je meer features aan toevoegt zijn er meer afslagen, en is er de kans dat je van mooie brede snelweg naar groot weiland gaat waar iedere richting mogelijk is en de gebruiker niet meer weet waar hij heen moet, en je dus je originele idee kwijt bent geraakt.
Maar ik moet eerlijk toegeven, ik zet zelf ook graag meer output (tijdelijk) op het scherm dan het initiële idee bevat, al is het maar om de berekeningen te controleren :)
En wat betreft koppige 'programmeurs' (veredelde html-tikkers bedoel ik hier) ik denk dat ik van geluk mag spreken dat ik die nog niet tegen het lijf ben gelopen. En in situaties waar het wel voorkomt dat html & php een stoelendans doen heb ik niet de rechten om het recht te zetten. Een template-engine is dan wel een mooie methode om die scheiding af te dwingen, om dat idee van programmeren aan te leren.
Korte samenvatting volgens mij: Template engines zijn handig om bepaalde programmeer-ideeën af te dwingen zonder de betreffende koppige programmeur constant op zijn vingers te tikken. Dat doet hij zelf wel door in de insert woord hier, ben uitdrukking vergeten te liggen met de template engine.