[php/html] php in html of html in php

[CHeff]

Ik gebruik(te) meestal methode 1.
Bovenin zet ik alle PHP code en onderin de HTML code waarin zo nu en dan een variabele op beeld wordt gegooid.

Maar nu ben ik toch maar eens aan het overstappen naar templates, is toch wel wat gestructureerder enzo

[Spider.007]

DDemolition schreef op vrijdag 20 januari 2006 @ 20:05:

PHP:

//of
require("Include.php")

//of
include("Include.php")

//of
require_once("Include.php")

gebruik ik ook soms in grote lappen om het overzichtelijk te houden. Is dit niet traag, omdat de server een php bestand moet 'openen' en dan als het waren in de huidige pagina moet parsen.

Het kost je filesysteem minimaal 1 extra read operatie; de snelheid daarvan is afhankelijk van je systeem en load

Verder heb ik af en toe moeite als ik zie hoe m'n html wordt uitgevoerd als ik naar de uiteindelijke bron kijk. Dit is door de 'for each' loops waarbij vaak 'if else' -en bij zijn komen kijken wat ver uitgetab'ed.

Wellicht is een eenvoudige templateparser dan wel een idee?

[pietje63]

Ik gebruik meestal een semi template systeem. Een main.php waarin ik verschillende pagina's include waaronder eentje die afhankelijk is van de mode variable (dus welke pagina je te zien krijgt).

De main.php is vrijwel alleen html met verder wat includes (functions.inc, database classes etc) en de pagina die ik (afhankelijk van de mode) include die is vooral code die html produceert (een beetje zoals in vb 2, maar dan in verhouding weinig html, en de html die er in staat op zich wel gewoon steeds op een nieuwe regel).

Ik heb trouwens een andere vraag.. Hoeveel gebruiken jullie \n als je html echoed. Ik eigenlijk nooit behalve als ik er het nut van zie (binnen mijn cms laat ik de html er wel netjes uitkomen, inclusief tabs en newlines, maar pure scripts eigenlijk niet omdat je die html toch niet hoeft te bekijken).

[Michali]

k8skaaay schreef op vrijdag 20 januari 2006 @ 18:23:
daar wordt het dus heel traag van.

Epitome schreef op vrijdag 20 januari 2006 @ 19:42:
Hoe meer er geparsed moet worden deste langzamer de pagina laadt, dus je PHP in de HTML zetten en niet andersom.

Wat een onzin argumenten hoor je toch altijd langskomen in dit soort topics. 2 voorbeelden zie je hierboven. Een beetje webhost heeft een optimizer geinstalleerd, daarmee elimineer je het tijdverlies doro parsing bijna helemaal. De tijd die je kwijt bent met het includen van een bestand is zo klein dat het bijna verwaarloosbaar is. Het wordt er dus zeer zeker niet heel traag van. Wat belangrijk is, is dat je een nette scheiding hebt tussen je logica en je presentatie, en als het even kan, ook nog een scheiding tussen je logica en je gegevens opslag. Als je veel php tussen je HTML hebt staan betekent dat vaak dat je je logica mixt met je presentatie, en dat is een slechte manier van werken. Je moet dan tussen je presentatie code gaan zitten zoeken naar functionaliteit die gewijzigd of gedebugged moet worden. Dat is zeker niet wat je wilt. Een beetje php tussen je HTML is zeker te rechtvaardigen. Het scheiden van code, die direct in relatie staat tot de presentatie, van de presentatie is eveneens fout. Dat hoort er zelfs tussen te staan.

Ik heb zelf verschillende methodes uitgeprobeerd. Ik ben zelf begonnen met PHP code direct te mixen met de HTML, maar daar begon ik al snel de nadelen van te merken en te voelen. Het is gewoon niet onderhoudbaar. Wil je een aanpassing in je ontwerp maken, dan zit je ook opgescheept met allerlei PHP code wat er weinig mee te maken heeft.

Hierna ben ik doorgegaan met het opbouwen van een associatieve array waarin alle waardes stonden, en dan een bestand te includen waarin die waardes uitgelezen werden, dat werkte al een stuk beter. Ik had echt nog wel alle logica tussen het opbouwen van die array staan, wat nog steeds nadelig was. Nog een stap verder is om al die logica naar aparte functies te verplaatsen en de code die de array opbouwt die functies op bepaalde momenten te laten aanroepen.

Uiteindelijk zijn die functies objecten geworden met bijbehorende data, en als presentatie gebruik ik nu classes die een stuk presentatie renderen. Daarbij heb ik dan een controller die de gegevens ophaalt (puur door middel van andere objecten) en een presentatie class instantieert met de gewenste data. Nu denk je mischien dat het mixen van HTML code in een class vreemd is, maar zo'n class heeft maar 1 enkele taak: het renderen van een stuk HTML. Als je dat aanhoudt, dan werkt dat perfect. Het afhandelen van acties gebeurt puur via de controller die andere objecten aanroept (en dus in feite zelf niets afhandelt, alleen doortstuurt). Deze manier van werken wordt ook wel het MVC (Model-View-Controller) pattern genoemd. Het opbouwen van een associatieve array en het includen van een bestand met HTML wat die array gebruikt is daar net zo goed een voorbeeld van (mits die code niets zelf afhandeld, maar alles doorstuurd (naar functies of objecten)), alleen dan niet object georienteerd.

Zelf werk ik altijd op deze manier:

PHP:

<ul>
<? foreach ( $object->getWaardes() as $waarde ) { ?>
    <li><?=$waarde?></li>
<? } ?>
</ul>

Of een iets complexer voorbeeld wat meer php code vraag (die dus wel bij je presentatie hoort):

PHP:

function printFields($fields)
{
?>
  <ul>
  <? foreach ( $fields as $field ) { ?>
    <li>
      <?=$field['value']?>
      <? if ( count($field['childFields']) > 0 ) printFields($field['childFields']); ?>
    </li>
  <? } ?>
  </ul>
<?
}

printFields($data['fields']);

Dit is voor mij de meest effectieve manier gebleken. Iedere regel php code die tussen HTML staat begint met <? en eindigt met ?>. Als je veel van die regels naast elkaar hebt staan, dan is het beter om dat door de controller te laten opbouwen en bepalen. Je voegt dan een extra stap tussen het renderen in. Dat maakt de HTML code een stuk duidelijker en gemakkelijker aanpasbaar.

[FragFrog]

Helmet schreef op vrijdag 20 januari 2006 @ 16:20:
in PHP maak ik zelf het liefst gebruik van templates, zo kan ik de content en de code geheel scheiden

HTML:

 <table> 
  {section name=bla loop=$bla}  
   <tr><td>{$bla[bla].naam}</td><td>{$bla[bla].telefoonnummer}</td></tr>
  {/section}
 </table>

Smarty!

Methode waarmee mijn pagina's opgebouwd worden:

TEMPLATE <- Data collecter <- Functions page <- db acces page <- DB

Omslachtig? Ja en nee. De template wordt gecached en is na een eerste aanroep razendsnel. Je kan verschillende data collecter pagina's bij een template hebben en vica versa om snel plugins etc te schrijven. Alle functies die vaker dan 1 keer gebruikt worden hoef je nooit meer te copy-pasten omdat je simpelweg de functions pagina include. Tenslotte is ook je database veilig achter een DB acces page (mits je die goed opbouwt natuurlijk ).

Voorbeeldje:

PHP:

<?php
/* Data collecter: */
require('includes/functions.inc.php');

initUserSession();

$userdata   = getUserData();

$smarty = new smarty_connect;
  $smarty->assign('userdata', $userdata);
  $smarty->display('battlefield.tpl');
?>

Wat dit doet is eerst de functions.inc.php pagina includen, welke oa de smarty template parser en database functies include. Vervolgens wordt de sessie gestart / gecontroleerd indien aanwezig, en wordt de userdata opgehaald mbv de getUserData functie. Vervolgens wordt er een nieuw template-object aangemaakt die $userdata als variabelen toegestuurd krijgt.

Wat ook nog eens een enorm voordeel hiervan is: in je template heb je in principe behalve smarty-tags alleen maar HTML en CSS nodig, en als je daar net als ik niet zo goed in bent kan iemand anders zonder enig verstand van PHP whatsoever je pagina in elkaar zetten

In het begin deed ik overigens ook nogal veel PHP met echo's erin, later werd dat een return string naar een weergave pagina en tegenwoordig dus templates

Optie die ik nog niet ben tegengekomen trouwens:

PHP:

<?php
$phpding = 'iets';
$output = 
  <<HTM
    <h2>HTM gedeelte :)</h2>
    Phpding is $phpding!
  HTM;
return $output;
?>

[ Voor 34% gewijzigd door FragFrog op 21-01-2006 13:55 ]

[Anoniem: 26306]

Ik gebruik niet "altijd" hetzelfde. Dat is een beetje afhankelijk van de hoeveelheid HTML en de hoeveelheid variabelen die daar ingeplakt moeten worden. Veel HTML? Dan PHP shorttags ertussendoor. Veel variabelen in 1 regel? Dan printf.

De heredoc syntax gebruik ik alleen nooit. Dan kun je beter een (template) bestand includen op die plaats. En aangezien PHP zelf al een template parser is, biedt iets als Smarty geen voordelen als je zelf alles van de website ontwikkelt (backend, markup, etc.), en je dus al PHP kent.

[FragFrog]

Anoniem: 26306 schreef op zaterdag 21 januari 2006 @ 13:52:
En aangezien PHP zelf al een template parser is, biedt iets als Smarty geen voordelen als je zelf alles van de website ontwikkelt (backend, markup, etc.), en je dus al PHP kent.

Niet met je eens. Natuurlijk, met PHP kun je hetzelfde voor elkaar krijgen (smarty is tenslotte niets meer dan een grote brok PHP), maar waarom het wiel opnieuw uitvinden? Een tijdje terug ben ik ook met een CMS bezig geweest, geweldig project samen met nog iemand vrolijk aan begonnen maar we zijn inmiddels al bijna een half jaar bezig en de eerste beta's zijn net klaar... Hadden we direct vanaf het begin wat standaart software gebruikt was dat ongetwijfeld een stuk korter geweest

Daarnaast is het gescheiden houden van markup en data OOK als je alles zelf ontwikkelt nuttig. Zeker bij grotere projecten krijg je anders al snel dubbele functies / markup etc. En ja, je kan daarvoor ook zelf templates maken en een template parse-functie in PHP inbouwen, en als je dan toch bezig bent een goede HTML cacher, maar waarom in godsnaam als je die functionaliteit zo van't net kan plukken?

[Anoniem: 26306]

FragFrog schreef op zaterdag 21 januari 2006 @ 14:13:


Niet met je eens. Natuurlijk, met PHP kun je hetzelfde voor elkaar krijgen (smarty is tenslotte niets meer dan een grote brok PHP), maar waarom het wiel opnieuw uitvinden?

Welk wiel uitvinden? Ik beheers PHP, ik beheers HTML, waarom zou ik een 3e "taal" toevoegen en de API van Smarty gaan leren? Dat is tamelijk zinloos, dacht ik zo. Er is weinig simpelers in PHP dan een boel variabelen bij elkaar rapen en een template bestand includen.

Een tijdje terug ben ik ook met een CMS bezig geweest, geweldig project samen met nog iemand vrolijk aan begonnen maar we zijn inmiddels al bijna een half jaar bezig en de eerste beta's zijn net klaar... Hadden we direct vanaf het begin wat standaart software gebruikt was dat ongetwijfeld een stuk korter geweest

Wij ontwikkelen al jaren aan een CMS en dat blijft ook maar doorgaan. Neemt niet weg dat een template engine daar helemaal niks mee te maken heeft. De output genereren is dermate simpel dat daar praktisch geen tijd in gaat zitten.

Daarnaast is het gescheiden houden van markup en data OOK als je alles zelf ontwikkelt nuttig.

Dat doe ik toch ook? Ik gebruik PHP op verschillende manieren, waarvan er één de template parser is. En ik voeg geen onnodige 3rd party library toe.

Zeker bij grotere projecten krijg je anders al snel dubbele functies / markup etc. En ja, je kan daarvoor ook zelf templates maken en een template parse-functie in PHP inbouwen,

Ik parse helemaal niks. PHP doet dat prima zelf. Gewoon PHP code tussen de HTML. Het belangrijkste is dat die code er alleen maar is om te helpen om de content te genereren. Het verwerken van data moet dan al lang gebeurd zijn.

en als je dan toch bezig bent een goede HTML cacher, maar waarom in godsnaam als je die functionaliteit zo van't net kan plukken?

Waarom iets van het net plukken als het nergens voor nodig is?

[FragFrog]

Anoniem: 26306 schreef op zaterdag 21 januari 2006 @ 15:40:
Dat doe ik toch ook? Ik gebruik PHP op verschillende manieren, waarvan er één de template parser is. En ik voeg geen onnodige 3rd party library toe.

[...]

Ik parse helemaal niks. PHP doet dat prima zelf. Gewoon PHP code tussen de HTML. Het belangrijkste is dat die code er alleen maar is om te helpen om de content te genereren. Het verwerken van data moet dan al lang gebeurd zijn.

PHP code tussen je HTML is mits je't netjes doet inderdaad een hip alternatief voor een template-enginge wat betreft data/markup gescheiden houden, ben ik met je eens. Helaas heeft niet iedereen dezelfde ervaring met zowel HTML als PHP, of zin zich met beide bezig te houden. Ik werk aan projecten vaak met meerdere mensen, vooral designers, die geen of nauwelijks verstand hebben van PHP. Ikzelf kan aan de andere kant HTML en CSS lezen maar slechts beperkt schrijven. Smarty templates hebben nogal wat shortcuts voor dingen die je anders met PHP relatief veel code kosten, zoals om maar iets te noemen de HTML options. Het is dan netter EN overzichtelijker om het met Smarty te doen vind ik (en velen met mij).

Daarnaast is er ook nog zoiets als snelheid, een gecachde HTML pagina laad nou eenmaal sneller dan een volledig dynamisch opgebouwde PHP pagina wat je zeker bij veelgebruikte websites wel degelijk gaat merken, maar dat hangt uiteraard wel af van de type content

[ Voor 3% gewijzigd door FragFrog op 22-01-2006 01:08 ]

[Bosmonster]

De Smarty syntax vind ik persoonlijk niet veel simpeler dan die van basic PHP. We hebben het hier dan uiteraard wel alleen over variabelen en control structures, als je PHP als template engine gebruikt. Voor dingen als options kun je ook helpers maken wat dat betreft om het proces te vereenvoudigen als het je stoort.

De enige reden die ik altijd zie om de overhead van een template engine als Smarty te nemen is als er mensen zijn die je wilt beperken in hun mogelijkheden in het gebruik van de templates. En dus geen volledige PHP controle wilt geven. Aangezien dat bij ons niet het geval is is de keuze ook simpel: schrap de template parser overhead.

Spider.007 schreef op vrijdag 20 januari 2006 @ 19:49:
Bij mij maakt _alles_ wat ik bouw gebruik van een (semi) fusebox, actionbased systeem. Ik heb dus altijd 1 script welke verschillende acties kan afhandelen. Al mijn PHP code is daarom om PHP code met soms HTML erdoorheen; nooit het tegenovergestelde Ik zie HTML graag als een uitvoerformaat van PHP en negeer de 'handige' optie van PHP om ook binnen HTMLcode aangeroepen te worden; dat vindt ik namelijk compleet onoverzichtelijk en onduidelijk

HTML als uitvoerformaat van PHP En jij bent 'parse-devver' Blij dat ik daar niet werk en jouw code hoef te onderhouden... (om het over het feit dat PHP ook wel eens wat anders dan HTML kan genereren maar niet te hebbn )

[ Voor 40% gewijzigd door Bosmonster op 22-01-2006 11:19 ]

[Spider.007]

Bosmonster schreef op zondag 22 januari 2006 @ 11:15:
[...]

HTML als uitvoerformaat van PHP En jij bent 'parse-devver' Blij dat ik daar niet werk en jouw code hoef te onderhouden... (om het over het feit dat PHP ook wel eens wat anders dan HTML kan genereren maar niet te hebbn )

Of jij begrijpt mij niet, of ik begrijp jou niet. Wat is je punt en hoe zou jij weten hoe mijn code eruit ziet en dat dat on-onderhoudbaar zou zijn?

[Anoniem: 43373]

Ik vind het wel apart dat over zoiets (toch wel basic) de meningen nog zo verdeeld zijn. Zowel over het al dan niet html als output van php toepassen, als over het al dan niet gebruik maken van templates. Ik had stiekem verwacht dat op mijn vraag een eensgezind antwoord zou komen. Beetje naïef natuurlijk.

Ik kan eigenlijk wat betreft de html/php output, concluderen dat het puur een persoonlijke structurele keuze blijft, en in principe geen van beiden afdoet aan de snelheid?

[ Voor 22% gewijzigd door Anoniem: 43373 op 23-01-2006 09:42 ]

[StevenK]

Ben net bezig een site om te knutselen waar ook een phpbb forum op draait en heb besloten om maar eens van de bijbehorende template-functionaliteit gebruik te maken.

Bevalt me uitstekend.

Ik heb één index.php die benaderbaar is; de rest van de code staat buiten de website, net zoals de templates en m'n code *en* de opmaak zijn ineens enorm overzichtelijk.

Alle andere dingen die ik tot nu gebouwd heb (vooral intranet meuk) is sowieso altijd een php pagina waarin de html gegenereerd wordt.

vaste structuur:

1. Eerst alle $_GET/$_POST verwerken die tot een redirect kan leiden
2. Data ophalen en tegelijkertijd omfabrieken naar HTML (of .xls, of .pdf of .jpg of wat het ook is dat die app doet)

Ik werk nu voor het eerst met losse templates en dat bevalt me echt uitstekend.

[ Voor 38% gewijzigd door StevenK op 23-01-2006 09:50 ]

[Bosmonster]

Spider.007 schreef op zondag 22 januari 2006 @ 15:13:
[...]
Of jij begrijpt mij niet, of ik begrijp jou niet. Wat is je punt en hoe zou jij weten hoe mijn code eruit ziet en dat dat on-onderhoudbaar zou zijn?

Al mijn PHP code is daarom om PHP code met soms HTML erdoorheen; nooit het tegenovergestelde

Oftewel je code is PHP met de html er overal een beetje doorheen verweven en noit het tegenovergestelde (PHP-in-html).. Niet echt het toppunt van onderhoudbaarheid als je wat aan de html wilt veranderen

Maar misschien snap ik je zin niet en bedoel je met 'PHP code met soms HTML erdoorheen' en 'nooit het tegenovergestelde' iets heel anders!

[ Voor 9% gewijzigd door Bosmonster op 23-01-2006 10:27 ]

[Anoniem: 26306]

Bosmonster schreef op maandag 23 januari 2006 @ 10:26:

Oftewel je code is PHP met de html er overal een beetje doorheen verweven en noit het tegenovergestelde (PHP-in-html).. Niet echt het toppunt van onderhoudbaarheid als je wat aan de html wilt veranderen

Helemaal mee eens. Daarom is het raar om "altijd het één" of "altijd het ander" te doen. Bij het initialiseren of het verwerken van gegevens kom je natuurlijk geen letter HTML tegen. Daar is het veel PHP code, met hier en daar een string, of stiekem toch al een beetje HTML dat in een buffer gezet wordt. Zulke bestanden beginnen met <?, eindigen met ?> en ertussendoor staat zuivere PHP code.

Zodra het verwerken van gegevens is gebeurd, wordt er door diverse classes en includes output gegenereerd of gebufferd, en de templates zijn dan weer voornamelijk HTML met een paar korte! stukjes PHP code ertussendoor met de <?=$var?> syntax. Dat is dus ook prima te begrijpen voor iemand die geen PHP kent, wél PHP herkent, en het is ook erg duidelijk.

Daarom dus gewoon per situatie bekijken wat het makkelijkst is.

[BarôZZa]

Het kan best handig zijn als de html simpel in elkaar steekt en bijvoorbeeld wordt opgemaakt met een CSS bestand.

Het voordeel van html-in-php vind ik dat je makkelijk kan zoeken naar de functie die een bepaald gedeelte van de html-code genereert in plaats van dat je door de html-code moet zwoegen naar het juiste gedeelte om vervolgens de php code aan te passen.

Ik zag daarnet bijvoorbeeld dit als voorbeeld:

Michali schreef op zaterdag 21 januari 2006 @ 12:06:
[...]

PHP:

<ul>
<? foreach ( $object->getWaardes() as $waarde ) { ?>
    <li><?=$waarde?></li>
<? } ?>
</ul>

Of een iets complexer voorbeeld wat meer php code vraag (die dus wel bij je presentatie hoort):

PHP:

function printFields($fields)
{
?>
  <ul>
  <? foreach ( $fields as $field ) { ?>
    <li>
      <?=$field['value']?>
      <? if ( count($field['childFields']) > 0 ) printFields($field['childFields']); ?>
    </li>
  <? } ?>
  </ul>
<?
}

printFields($data['fields']);

[...]

Ongetwijfeld net wat sneller, maar om daarna iets te veranderen lijkt me een ramp, aangezien php en html continu met elkaar worden afgewisseld.

[Anoniem: 26306]

Oplossing: een include gebruiken. Ofwel een losse include, want met zo'n simpele functie is een functieaanroep overdreven, dan kun je beter net zo goed alleen een file includen.

Of als je per se een beperkte scope wilt, of een iets complexere functie hebt, kun je de logica in die functie zetten, en de output alsnog in een template bestand zetten en die binnen de functie includen.

[sariel]

Anoniem: 26306 schreef op zaterdag 21 januari 2006 @ 15:40:
[...]

Welk wiel uitvinden? Ik beheers PHP, ik beheers HTML, waarom zou ik een 3e "taal" toevoegen en de API van Smarty gaan leren? Dat is tamelijk zinloos, dacht ik zo. Er is weinig simpelers in PHP dan een boel variabelen bij elkaar rapen en een template bestand includen.

[...]

Ik parse helemaal niks. PHP doet dat prima zelf. Gewoon PHP code tussen de HTML. Het belangrijkste is dat die code er alleen maar is om te helpen om de content te genereren. Het verwerken van data moet dan al lang gebeurd zijn.

[...]

Waarom iets van het net plukken als het nergens voor nodig is?

Je hoeft ook geen andere template engine ergens vandaan te plukken als je die toch niet fijn vind, of je eigen hebt. Echter, PHP code tussen den HTML is echt zo ongeveeer het ergste wat je kan doen: Zo vaak gebeurd het, en het zorgt 99% van de tijd voor compleet onleesbare en onbeheerbare code.
Het mag *misschien* iets sneller zijn (misschien, omdat er vaak caching is door de template engines), maar het weegt niet op tegen de onbeheersbaarheid van het hele ding.
Stel, jij gaat weg. Er komt iemand nieuw binnen. Die moet ff de CMS aanpassen, omdat een of andere klant een andere vormgeving wil hebben. Die zit dan echt helemaal in de knoei.

Ik geef je wel gelijk dat je al het verwerken van de data niet op dezelfde plaats als de output doet, dat is inderdaad wel een goede manier van werken, want dan kan je gewoon je data aanpassen, en je output heeft er weinig last van (mits je de data op dezelfde manier aanlevert).

Ik zelf gebruik bijna altijd templates en zo (alleen niet als ik een scriptje van +- 20-50 regels, inclusief witregels en comments, heb). Ik heb (toen ik nog dom en onervaren was) vroeger wel PHP code door m'n HTML gedaan (ook bij grotere projecten), en dat soort code is 2 maanden later al eigenlijk niet meer werkbaar......

[Anoniem: 26306]

sariel schreef op maandag 23 januari 2006 @ 11:03:

Je hoeft ook geen andere template engine ergens vandaan te plukken als je die toch niet fijn vind, of je eigen hebt. Echter, PHP code tussen den HTML is echt zo ongeveeer het ergste wat je kan doen: Zo vaak gebeurd het, en het zorgt 99% van de tijd voor compleet onleesbare en onbeheerbare code.

Dat ligt aan de programmeur, niet aan het principe. Als je niet kan programmeren wordt élk script een rommeltje.

Het mag *misschien* iets sneller zijn (misschien, omdat er vaak caching is door de template engines), maar het weegt niet op tegen de onbeheersbaarheid van het hele ding.
Stel, jij gaat weg. Er komt iemand nieuw binnen. Die moet ff de CMS aanpassen, omdat een of andere klant een andere vormgeving wil hebben. Die zit dan echt helemaal in de knoei.

Absoluut niet. Alles is wat mij betreft duidelijk genoeg. Het bewerken van de output templates die wat PHP code bevatten is niet moeilijker dan het bewerken van bestanden die code van een of andere template engine bevatten.

Ik geef je wel gelijk dat je al het verwerken van de data niet op dezelfde plaats als de output doet, dat is inderdaad wel een goede manier van werken, want dan kan je gewoon je data aanpassen, en je output heeft er weinig last van (mits je de data op dezelfde manier aanlevert).

Daar zijn we het kennelijk over eens, en dat geldt trouwens voor zo ongeveer elke programmeer- of opmaaktaal, of het nu PHP is, HTML, Javascript, CSS, of wat dan ook. Zulke zaken scheiden bevordert de onderhoudbaarheid meestal. Dat is afhankelijk van de auteur uiteraard.

Ik zelf gebruik bijna altijd templates en zo (alleen niet als ik een scriptje van +- 20-50 regels, inclusief witregels en comments, heb). Ik heb (toen ik nog dom en onervaren was) vroeger wel PHP code door m'n HTML gedaan (ook bij grotere projecten), en dat soort code is 2 maanden later al eigenlijk niet meer werkbaar......

Dat lag dan aan je onervarenheid, niet aan het principe. Als je nu weer "terugschakelt" naar PHP templates, en de rest van je werkwijze hetzelfde houdt als je nu doet, is alles ongetwijfeld prima onderhoudbaar.

[Spider.007]

Bosmonster schreef op maandag 23 januari 2006 @ 10:26:
[...]


[...]

Oftewel je code is PHP met de html er overal een beetje doorheen verweven en noit het tegenovergestelde (PHP-in-html).. Niet echt het toppunt van onderhoudbaarheid als je wat aan de html wilt veranderen

Het is maar net vanuit welk standpunt je kijkt, logica van de PHP, of de uitvoer van HTML. Sowieso gebruik ik primair een eenvoudige template-engine voor de wat grotere applicaties; maar mijn kleine pagina's zijn PHP met HTML; en geen HTML met PHP

[Cartman!]

Hier nog een template gebruiker (ik gebruik een aangepaste versie van Yapter zodat ie in PHP4&5 vlekkeloos werk) en dat bevalt meer dan goed. Geen opmaak meer in je PHP zorgt ervoor dat je relatief simpel je hele site kunt wijzigen. Zo had ik laatst een site gebouwd die uiteindelijk toch n ander design kreeg. Kon gewoon de template wijzigen en hops, in n paar uurtjes stond de nieuwe site al. Vet handig En t bespaard n hoop zoekwerk ook, dat vind ik persoonlijk t grootste voordeel.

[Anoniem: 112721]

FragFrog schreef op zondag 22 januari 2006 @ 01:07:Daarnaast is er ook nog zoiets als snelheid, een gecachde HTML pagina laad nou eenmaal sneller dan een volledig dynamisch opgebouwde PHP pagina wat je zeker bij veelgebruikte websites wel degelijk gaat merken, maar dat hangt uiteraard wel af van de type content

Smarty cached op twee manieren:
1. Compileert de template, zodat dit niet nogmaals hoeft te gebeuren.
2. Cached de HTML output, zodat niet elke keer naar de database gegaan hoeft te worden (dit staat niet standaard aan in Smarty).

ad1) Smarty compileert dus de template... hij compileert dit naar PHP! Dus Smarty is een extra zinloze parser-stap (ondanks dat deze bij de eerste aanroep wordt opgelagen als PHP). Een extra programmeertaal boven op PHP: je schrijft in Smarty, wat gecompileerd wordt naar PHP...

ad2) Dit heeft veel voordelen, maar dit kan ook simpel zelfgeschreven worden of je gebruikt hiervoor een third-party applicatie die een veel kleinere 'foot'-print heeft, dan Smarty. In je zelf geschreeven code kun je dan ook nog gebruik maken van caching volgens het HTTP-protocol, wat nog sneller is dan HTML cachen en bandbreedte spaart: er worden dan vrijwel alleen HTTP-headers verstuurt.

FragFrog schreef op zondag 22 januari 2006 @ 01:07:Helaas heeft niet iedereen dezelfde ervaring met zowel HTML als PHP, of zin zich met beide bezig te houden. Ik werk aan projecten vaak met meerdere mensen, vooral designers, die geen of nauwelijks verstand hebben van PHP.

En? Kunnen ze wel de Smarty-syntax? Die moeten ze ook leren. Of ze nu Smarty-syntax leren of een paar dingetjes van PHP, dat maakt voor een designer niets uit. Het enige gevaar is dat ze meer kunnen doen, wat je als programmeur niet zou willen, als ze PHP een beetje doorkrijgen, maar ik vertouw de designers hierin geen misbruik van te maken (maar dat ligt ook wat voor opdrachten je doet en met wat voor een team).

[FragFrog]

Anoniem: 112721 schreef op maandag 23 januari 2006 @ 13:01:
ad2) Dit heeft veel voordelen, maar dit kan ook simpel zelfgeschreven worden of je gebruikt hiervoor een third-party applicatie die een veel kleinere 'foot'-print heeft, dan Smarty. In je zelf geschreeven code kun je dan ook nog gebruik maken van caching volgens het HTTP-protocol, wat nog sneller is dan HTML cachen en bandbreedte spaart: er worden dan vrijwel alleen HTTP-headers verstuurt.


[...]
En? Kunnen ze wel de Smarty-syntax? Die moeten ze ook leren. Of ze nu Smarty-syntax leren of een paar dingetjes van PHP, dat maakt voor een designer niets uit. Het enige gevaar is dat ze meer kunnen doen, wat je als programmeur niet zou willen, als ze PHP een beetje doorkrijgen, maar ik vertouw de designers hierin geen misbruik van te maken (maar dat ligt ook wat voor opdrachten je doet en met wat voor een team).

Puntje 1: uiteraard zet ik waar mogelijk ook smarty's HTML caching aan, anders heeft het inderdaad voor snelheid weinig nut. Maar je moet eens opletten hoeveel websites, ook dynamische als bijvoorbeeld een forum, slechts enkele keren per dag geupdate worden terwijl ze wel duizenden keren per dag opgevraagd worden. En je hebt gelijk dat daar ook andere applicaties voor zijn, maar als m'n template parser het ook kan gebruik ik persoonlijk liever die. Ookal om punt 2:

De designers waar ik mee samen werk kennen geen smarty-syntaxen, of in ieder geval nauwelijks. Wat zij aanleveren is losse HTML + CSS, waarna ik hun broncode in een tpl gooi en alles wat dynamisch is vervang door SMARTY. Vooral heel veel standaart HTML dingen zijn daarin een stuk sneller te coden dan wanneer je't met PHP zou doen (zoals het al eerder vermelde option/select input type).

Maargoed, uiteindelijk blijft het een kwestie van smaak gok ik.. Persoonlijk zie ik voordelen in het gebruik van een template-parser (al was het alleen maar omdat je zulke nette en efficiente HTML code erdoor krijgt - alleen al een variabele weergeven is met {$var} een stuk netter IMHO dan <?=$var?>), maar ik kan me goed voorstellen dat die paar kleine voordelen voor anderen niet groot genoeg zijn om over te stappen op het gebruik van een dergelijk pakket.

[BarôZZa]

Het grootste nadeel vind ik dat SMARTY geen bekende standaard is. Je zegt zelf dat jij de code van anderen vervangt voor SMARTY, waarna zij er niks meer mee kunnen. Zeker wanneer je met meerdere mensen aan een project werkt is dat vrij onhandig.

Ik kan me ook goed voorstellen dat andere mensen niet willen dat je bijvoorbeeld hun site in SMARTY maakt en dan is het een aardige belemmering aangezien je dan helemaal gewend bent aan het maken en onderhouden van sites daarmee.

[Michali]

Anoniem: 112721 schreef op maandag 23 januari 2006 @ 13:01:
ad1) Smarty compileert dus de template... hij compileert dit naar PHP! Dus Smarty is een extra zinloze parser-stap (ondanks dat deze bij de eerste aanroep wordt opgelagen als PHP). Een extra programmeertaal boven op PHP: je schrijft in Smarty, wat gecompileerd wordt naar PHP...

Begrijp me niet verkeerd, ik ben het met je eens dat een template parser in veel gevallen ongewenst is en dat het extra complexiteit en overhead meebrengt terwijl het totaal onnodig is. Het argument hierboven vind ik echter onzin. Een extra tussenstap, om veel uitgevoerde taken te kunnen optimaliseren is juist wel gewenst. Dat Smarty naar PHP code compileert, is dan alleen maar goed, omdat het zaken dan goed optimaliseert. Je zou dan ook kunnen zeggen dat JSP onzin is omdat het intern naar Servlets gecompileert wordt. Je zou ook kunnen zeggen dat je alles ad-hoc moet proggen, omdat het creeren van een domein/business layer naast een DAL en DBAL overbodig werk is, wat natuurlijk grootse onzin is. Het laten genereren van PHP code middels een stap die minder werk vereist is in geval van een template parser helemaal geen gek idee, sterker nog, dat is precies wat je wilt.

[ Voor 3% gewijzigd door Michali op 23-01-2006 22:47 ]

[PrisonerOfPain]

Michali schreef op maandag 23 januari 2006 @ 22:46:
[...]

Begrijp me niet verkeerd, ik ben het met je eens dat een template parser in veel gevallen ongewenst is en dat het extra complexiteit en overhead meebrengt terwijl het totaal onnodig is. Het argument hierboven vind ik echter onzin.

Daar komt nog eens bij dat het minder foutgevoelig is {Var} vs. <?php if(isset($var)) echo htmlentities($var, ENT_QUOTES); ?>

[Michali]

Persoonlijk heb liever de laatste, omdat ik dan meer controle heb. Ik zou dan voor iets als <?=isset($var) ? htmlentities($var) : ''?>. Klopt het dan die hoofdletter betekent dat htmlentities er overheen gehaald wordt, en dat het anders met rust gelaten wordt? Ik print namelijk nog wel eens javascript uit, dan zou een htmlentities fataal zijn.

[Anoniem: 26306]

PrisonerOfPain schreef op dinsdag 24 januari 2006 @ 00:01:

Daar komt nog eens bij dat het minder foutgevoelig is {Var} vs. <?php if(isset($var)) echo htmlentities($var, ENT_QUOTES); ?>

Wat is minder foutgevoelig? Wat als er HTML op de plaats van die {Var} moet komen? Dat kan ik nergens uit opmaken hoor? En wat als er vooral geen rauwe HTML mag komen?

En als je die ene regel PHP code "onduidelijk" vindt, moet je nodig een andere hobby nemen. Wat er precies gebeurt wordt niet duidelijker dan dat. Het staat er letterlijk.

offtopic:
Overigens mag ik hopen dat je zelf wel een escape functie hebt voor HTML, Javascript, etc.

[PrisonerOfPain]

Anoniem: 26306 schreef op dinsdag 24 januari 2006 @ 00:20:
[...]

Wat is minder foutgevoelig?

Minder tekens, minder denkwerk dus minder foutgevoelig.

Wat als er HTML op de plaats van die {Var} moet komen?

{Var:r} Of {Var:u} voor urlencoded. Flexy .

Dat kan ik nergens uit opmaken hoor?

Daarom zijn de meeste template eninges met een documentatie uitgerust, daar staan dat soort dingen in omschreven.

En als je die ene regel PHP code "onduidelijk" vindt, moet je nodig een andere hobby nemen.

Waar lees jij dat ik die onduidelijk vind? Sterker nog, dat vind ik niet. Het is me enkel teveel moeite om het iedere keer in te tikken. Helemaal als de gecompileerde versie van de template uiteindelijke dezelfde broncode oplevert. Overigens zou een vriendelijkere toon niet misstaan.

Wat er precies gebeurt wordt niet duidelijker dan dat. Het staat er letterlijk.

Dan wat? Voor dat soort gevallen is documentatie toch uitgevonden? En wat moet je uberhaupt met een template engine als je niet weet wat de consequenties van je acties zijn?

offtopic:
Overigens mag ik hopen dat je zelf wel een escape functie hebt voor HTML, Javascript, etc.

Nee, die heeft PHP immers al.

Michali schreef op dinsdag 24 januari 2006 @ 00:14:
Persoonlijk heb liever de laatste, omdat ik dan meer controle heb.

Waar heb je al die controle zoal voor nodig dan? Zoals hierboven aangehaald, onder Flexy heb je een aantal modifiers waarmee je je content kan vervormen, default is het htmlentities die er overheen gehaald word.

[ Voor 14% gewijzigd door PrisonerOfPain op 24-01-2006 00:59 ]

[Grijze Vos]

FragFrog schreef op zaterdag 21 januari 2006 @ 14:13:
[...]


Niet met je eens. Natuurlijk, met PHP kun je hetzelfde voor elkaar krijgen (smarty is tenslotte niets meer dan een grote brok PHP), maar waarom het wiel opnieuw uitvinden?

PHP is een scripting taal. PHP is een template engine (in weze). Dan is het toch juist Smarty die het wiel opnieuw uitvindt?

---

Persoonlijk vind ik iets als

code:

<?php
  foreach($bla as $key => $bliep)
  {
    echo "<tr><td>" . $bliep . "</td></tr>";
  }
?>

dan weer lekkerder werken als

code:

<?php
  foreach($bla as $key => $bliep)
  {
    ?><tr><td><?=$bliep?></td></tr><?
  }
?>

Ik vind al die open en close tags niet echt logisch, het breekt het overzicht van je control structure af. Maar uiteindelijk komt het neer op flavour. Er zijn niet echt voors of tegens, gewoon persoonlijke voorkeuren.

Overigens, mijn code-layer die output genereert gaat object-georienteerd, ik heb eigenlijk nooit geprobeerd om de php af te sluiten en te resumen midden in een class, is dat uberhaupt mogelijk?

[.oisyn]

Epitome schreef op vrijdag 20 januari 2006 @ 19:42:
Hoe meer er geparsed moet worden deste langzamer de pagina laadt, dus je PHP in de HTML zetten en niet andersom.

Onzin. Allereerst heeft het niets met parsen te maken, maar met lexical analysen (of scannen), maar zowel parsers als scanners werken over het algemeen in O(n) met n het aantal tekens (voor scanners) of tokens (voor parsers). Het zijn statemachines die hun actie bepalen aan de hand van hun huidige state en het volgende teken/token. Op die manier is een single-quoted string dus niet sneller dan een double-quoted string, en ook niet langzamer dan dezelfde hoeveelheid tekens in html-mode. Verder is zowel een stuk html als een string gewoon 1 token, dus het komt er effectief op neer dat wat het kortste is het snelst is. Echter, zoals Michali al aanhaalde, is dit nogal verwaarloosbaar en zul je het pas echt merken bij hele grote scripts (hoewel die grotere scripts ook meer werk doen, waardoor de snelheidswinst in verhouding opnieuw verwaarloosbaar is)

[ Voor 6% gewijzigd door .oisyn op 24-01-2006 01:44 ]

[Anoniem: 105758]

gebruik wel <?PHP ipv <?

Het komt zelden voor dat het niet werkt, maar ja die ene keer he

Verder doe ik het zo binnen html <?PHP stuk code ?>

[HyperioN]

Anoniem: 105758 schreef op dinsdag 24 januari 2006 @ 02:05:
gebruik wel <?PHP ipv <?

Het komt zelden voor dat het niet werkt, maar ja die ene keer he

Verder doe ik het zo binnen html <?PHP stuk code ?>

Mag ik je er dan ook aan herinneren dat het al enkele jaren "standaard" is dat alle HTML-tags in lowercase (kleine letters) worden genoteerd?
Het moet dus

HTML:

<?php
    //code
?>

zijn...

[pietje63]

HyperioN. schreef op dinsdag 24 januari 2006 @ 02:13:
[...]

Mag ik je er dan ook aan herinneren dat het al enkele jaren "standaard" is dat alle HTML-tags in lowercase (kleine letters) worden genoteerd?
Het moet dus

HTML:

<?php
    //code
?>

zijn...

Als je dan toch gaat mierenneuken dan moet je <PHP ook geen html tag noemen...

[Michali]

Grijze Vos schreef op dinsdag 24 januari 2006 @ 01:12:
Persoonlijk vind ik iets als

code:

<?php
  foreach($bla as $key => $bliep)
  {
    echo "<tr><td>" . $bliep . "</td></tr>";
  }
?>

dan weer lekkerder werken als

code:

<?php
  foreach($bla as $key => $bliep)
  {
    ?><tr><td><?=$bliep?></td></tr><?
  }
?>

Totdat je extra HTML en/of attributen moet toevoegen:

code:

<?php
  foreach($bla as $key => $bliep)
  {
    echo "<tr class=\"een-class\"><td colspan=\"2\">" . $bliep . "</td></tr>";
  }
?>

vs.

code:

<?php
  foreach($bla as $key => $bliep)
  {
    ?><tr class="een-class"><td colspan="2"><?=$bliep?></td></tr><?
  }
?>

Zelf doe ik het nog anders, namelijk zo:

code:

<? foreach($bla as $key => $bliep) { ?>
    <tr class="een-class"><td colspan="2"><?=$bliep?></td></tr>
<? } ?>

Dan staat de HTML altijd helemaal los van de php stukken.

[ Voor 26% gewijzigd door Michali op 24-01-2006 09:51 ]

[pietje63]

Michali je laatste leest weer een stuk minder fijn.. ik zou zelf dan eerder

code:

foreach($bla as $key => $bliep) 
  { 
  ?>
  <tr class="een-class"><td colspan="2"><?=$bliep?></td></tr>
  <?
  }

Gebruiken (als escape ik heel vaak zelf zoals op je eerste manier.. niet ideaal, I know)

[ Voor 17% gewijzigd door pietje63 op 24-01-2006 10:16 ]

[Anoniem: 26306]

PHP:

<? foreach ( $arr as $key => $value ): ?>
   <tr class="een-class">
      <td scope="row"><?=$value?></td>
      <td><?=$key?></td>
   </tr>
<? endforeach ?>

Dit is een uitermate geschikte syntax voor de template mogelijkheden van PHP.

[Michali]

@Cheatah: Dat is idd mischien wel de beste methode. Ik zou dat ook meer moeten gebruiken.

@pietje63: Dat is voor mij niet compact genoeg. Vergelijk dit maar eens:

PHP:

<table>
    <thead>
        <tr>
        <? foreach ( $fields as $field ) { ?>
            <th><?=$field?></th>
        <? } ?>
        </tr>
    </thead>
    <tbody>
    <? foreach ( $rows as $row ) { ?>
        <tr>
        <? foreach ( $fields as $field ) { ?>
            <td><?=$row[$field]?></td>
        <? } ?>
        </tr>
    <? } ?>
    </tbody>
</table>

Of:

PHP:

<table>
    <thead>
        <tr>
        <?
        foreach ( $fields as $field )
            {
            ?>
            <th><?=$field?></th>
            <?
            }
            ?>
        </tr>
    </thead>
    <tbody>
    <?
    foreach ( $rows as $row )
        {
        ?>
        <tr>
        <?
        foreach ( $fields as $field )
            {
            ?>
            <td><?=$row[$field]?></td>
            <?
            }
            ?>
        </tr>
        <?
        }
        ?>
    </tbody>
</table>

Ik vind de 2de er echt niet duidelijker of overzichtelijker op worden. Eerder onduidelijker en minder logisch gestructureerd.

[ Voor 84% gewijzigd door Michali op 24-01-2006 10:39 ]

[BarôZZa]

Zelf stoor ik me dan vooral aan dingen als dit die je krijgt wanneer je php tussen de html propt:

PHP:

<? } ?> 

PHP:

            <? 
            } 
            ?> 

Ik gebruik het zelf dus door elkaar.

Bij de globale layout.php wel gewoon html met een paar php variables ertussen. Maar die vars bevatten vaak weer html.

PHP:

$mainpart="<table>";

for(hoppa){

    $mainpart.="<tr><td>$random</td></tr>";

}

$mainpart.="</table>";

PHP:

<html><body> + hele layout

<? echo $navigationarea ?>

...

<? echo $mainpart ?>

rest van de layout
</body></html>

Wanneer het overgrote deel html is dan is het dus html met php. Voor de (kleinere) stukken die grotendeels dynamisch gegenereerd worden door het php-script kies ik voor php met html.

Ik hou er zelf niet van wanneer er in for/if-clauses de php tags worden afgesloten en daarna weer worden geopend om het af te sluiten met een }.

[ Voor 30% gewijzigd door BarôZZa op 24-01-2006 10:55 ]

[Verwijderd]

Ik heb op een paar plekken nog html in mn php zitten, maar probeer 't zoveel mogelijk te scheiden in een template. Een php-script haalt de juiste data op en voegt samen met een ubersimpele templateparser.

Om een navigatiemenu te genereren gebruik ik wel html in php, omdat het imo niet te doen is dit goed te scheiden.

[Anoniem: 43373]

Verwijderd schreef op dinsdag 24 januari 2006 @ 10:57:Om een navigatiemenu te genereren gebruik ik wel html in php, omdat het imo niet te doen is dit goed te scheiden.

Ik zie geen reden waarom je alles zou kunnen scheiden, behalve een navigatiemenu.

Ik ben nu aan het kijken naar smarty. Ben benieuwd wat ik daar mee doe. Ik ben nog steeds liefhebber van html met daarin php ipv andersom, maar aan de andere kant kunnen dingen ook dan juist weer onoverzichtelijk worden als je niet goed gebruik maakt van templates of ander soort iets.
Het is makkelijk te vergelijken als je één table row hebt met één array, maar zo gaat 't toch meestal niet.

Het volgende is eigenlijk alweer een stukje groter, maar nog steeds bijna het minimum wat je hebt als je een array toont.

php tussen html

PHP:

<?
$userlist = User::get_userlist();
?>
<table>
    <? 
    if (!empty($userlist)) { 
        foreach ($userlist as $user) { ?>
            <tr>
                <td><?=$user['name']?></td>
                <td>
                    <? if ($user['avatar']) { ?>
                        [img]"<?=$user['avatar']?>"[/img]
                    <? } ?>
                </td>
            </tr>
        <? }
    } else { ?>
        <tr>
            <td>Geen gebruikers aanwezig</td>
        </tr>
    <?
    } 
    ?>
</table>

html in php

PHP:

<?
$userlist = User::get_userlist();
echo "<table>";
    if (!empty($userlist)) {
        foreach ($userlist as $user) {
            echo "<tr><td>" . $user['name']; . "</td>";
            if ($user['avatar']) {
                echo "<td>[img]\""[/img]</td>";
            }
            echo "</tr>";
        }
    } else {
        echo "<tr><td>Geen gebruikers aanwezig</td></tr>";
    }
echo "</table>";
?>

Ik had verwacht dat het misschien in dit geval toch gestructureerder zou kunnen zijn om de html in php te zetten, maar je hebt zo toch helemaal geen overzicht van de rows en cells. Dus ook al is het een regel of 9 korter, er is niet echt overzicht. Maarja, al vind ik manier 1 beter, ik vind het nog steeds niet ideaal.

En stel je hebt 10 arrays op 1 pagina; dan praat je wel over 90 regels code verschil.

Ben benieuwd of templating iets aan deze structuur veranderd. Je zult hoe dan ook toch ipv deze foreach een andere aanduiding hebben om door de array te loopen. En tussendoor andere checks.

[ Voor 28% gewijzigd door Anoniem: 43373 op 25-01-2006 13:09 ]

[BarôZZa]

Gewoon wat witregels en een andere indeling zorgt al voor veel meer overzicht

PHP:

<? 
$userlist = User::get_userlist(); 

echo "<table>"; 

  if (empty($userlist))
     echo "<tr><td>Geen gebruikers aanwezig</td></tr>"; 

  else

     foreach ($userlist as $user){

         echo "<tr><td>" . $user['name']; . "</td>"; 

         if ($user['avatar']) 
             echo "<td>[img]\""[/img]</td>"; 
            
         echo "</tr>"; 
    } 

echo "</table>"; 

?>

edit: laat maar, beetje verkeerd gelezen. Bedoelde dus dat <tr><td> gedoe. Vind het zelf niet echt belangrijk wanneer een script de html genereert. Wanneer je handmatig de html bewerkt is het wel handig omdat je dan gelijk ziet op welk 'niveau' je werkt binnen de tabel. Bij scripts vind ik dat niet belangrijk.

[ Voor 93% gewijzigd door BarôZZa op 25-01-2006 13:24 ]

[DDemolition]

Vaak vind ik voor het overzicht dit:

PHP:

<?
if (functie() == true)
    {
    doehetene();
    }
else
    {
    doehetandere();
    }
?>

fijner als dit met die {} haakjes:

PHP:

<?
if (functie() == true) {
    doehetene();
    }
else {
    doehetandere();
    }
?>

zal nog wel vastgeroeste VB stijl zijn bij me.

[Erkens]

BarôZZa schreef op woensdag 25 januari 2006 @ 13:18:
edit: laat maar, beetje verkeerd gelezen. Bedoelde dus dat <tr><td> gedoe. Vind het zelf niet echt belangrijk wanneer een script de html genereert. Wanneer je handmatig de html bewerkt is het wel handig omdat je dan gelijk ziet op welk 'niveau' je werkt binnen de tabel. Bij scripts vind ik dat niet belangrijk.

het is juist wel handig om nette output code te genereren zodat je sneller kan zien of er wat fout gaat.

[BasieP]

DDemolition schreef op woensdag 25 januari 2006 @ 13:26:[...]

How about:

PHP:

<?
if (functie())
    doehetene()
else
    doehetandere();
?>

of met meerdere regels

PHP:

<?
if (functie()) {
    doehetene();
    doehetene();
} else {
    doehetandere();
    doehetandere();
}
?>

[ Voor 29% gewijzigd door BasieP op 25-01-2006 13:33 ]

[Anoniem: 26306]

Doe het dan gewoon zo:

PHP:

<? $userlist = User::get_userlist(); ?> <!-- dit hoort hier eigenlijk niet -->
<table>
   <? if (!empty($userlist)): ?>
      <? foreach ($userlist as $user): ?>
         <tr>
            <td><?=$user['name']?></td>
            <td>
               <? if (!empty($user['avatar'])): ?>
                  [img]"<?=$user['avatar']?>"[/img]
               <? endif; ?>
            </td>
         </tr>
      <? endforeach; ?>
   <? else: ?>
      <tr>
         <td>Geen gebruikers aanwezig</td>
      </tr>
   <? endif; ?>
</table>

[BarôZZa]

Erkens schreef op woensdag 25 januari 2006 @ 13:31:
[...]

het is juist wel handig om nette output code te genereren zodat je sneller kan zien of er wat fout gaat.

Bij tabellen heb ik eigenlijk nooit dat het fout gaat. En anders zie je gelijk waar het verkeerd gaat door het simpelweg te bekijken.

[Bosmonster]

Anoniem: 26306 schreef op woensdag 25 januari 2006 @ 13:33:
Doe het dan gewoon zo:

PHP:

<? $userlist = User::get_userlist(); ?> <!-- dit hoort hier eigenlijk niet -->
<table>
   <? if (!empty($userlist)): ?>
      <? foreach ($userlist as $user): ?>
         <tr>
            <td><?=$user['name']?></td>
            <td>
               <? if (!empty($user['avatar'])): ?>
                  [img]"<?=$user['avatar']?>"[/img]
               <? endif; ?>
            </td>
         </tr>
      <? endforeach; ?>
   <? else: ?>
      <tr>
         <td>Geen gebruikers aanwezig</td>
      </tr>
   <? endif; ?>
</table>

Precies.. dat is de PHP template syntax, die veel mensen niet eens kennen (omdat ze PHP zelf niet als template engine gebruiken).

[Michali]

Dit vind ik nou mooie voorbeelden. Het laatste stukje code van velo en hoe Cheatah het oplost. In het eerste stuk moet je bijna gaan zoeken naar je HTML, de focus ligt gewoon veel meer op de PHP code, terwijl het doel van de code HTML output is, de focus zou juist op de HTML moeten liggen, en de PHP code meer op de achtergrond houden. In het geval van Cheatah's code zie je precies dat gebeuren. Je kunt de HTML veel beter van de PHP onderscheiden. Sterker nog, het is gescheiden. Dat is ook het hele punt. Imo moet je het uitprinten van HTML doormiddel van een echo of print statement altijd zien te voorkomen. Beter is om gewoon naar HTML modus te swichten en daar je HTML te schrijven. Dat maakt het onderhouden ervan ook een stuk gemakkelijker.

[Anoniem: 43373]

Michali schreef op woensdag 25 januari 2006 @ 13:51:
Dit vind ik nou mooie voorbeelden. Het laatste stukje code van velo en hoe Cheatah het oplost.

Ja dat schiet op, mijn stukje code waarvan ik al aangeef dat ik het onoverzichtelijk vindt, vergelijken met Cheatah's code die gebaseerd is op mijn andere stuk code.

@ Cheatah, in principe is wat je daar zet vrijwel hetzelfde als wat ik plaats. Alleen je hebt andere open en sluit manier. Er valt zeker iets voor te zeggen. Er is al wat meer overzicht doordat je iets minder hoeft te kijken wat je waar afsluit. Ik was altijd al geneigd om na het afsluiten er alsnog bij te zetten wat ik daar nou eigenlijk afsloot.

Anoniem: 26306 schreef op woensdag 25 januari 2006 @ 13:33:

PHP:

<? $userlist = User::get_userlist(); ?> <!-- dit hoort hier eigenlijk niet -->

Waar wil je het anders laten als je niet met templates werkt? Ik werk op dit moment gewoon met classes die ik require(); Je zult toch ergens je data in die page moeten krijgen? Ik verzamel dan usually alle date bovenaan de page, en start daarna de html. Toch niet zo verkeerd?

[Janoz]

De userlist opvragen is niet iets dat je vlak voor je tabel doet. Het opvragen van de userlist is onderdeel van je 'buisness logic' en niet van je layout. Ikzelf doe dat soort acties altijd bovenaan in de php pagina. Pas als alle acties gelukt en alle gegevens opgehaald zijn begin ik met de html.

[We Are Borg]

Anoniem: 26306 schreef op woensdag 25 januari 2006 @ 13:33:
Doe het dan gewoon zo:

PHP:

<? $userlist = User::get_userlist(); ?> <!-- dit hoort hier eigenlijk niet -->
<table>
   <? if (!empty($userlist)): ?>
      <? foreach ($userlist as $user): ?>
         <tr>
            <td><?=$user['name']?></td>
            <td>
               <? if (!empty($user['avatar'])): ?>
                  [img]"<?=$user['avatar']?>"[/img]
               <? endif; ?>
            </td>
         </tr>
      <? endforeach; ?>
   <? else: ?>
      <tr>
         <td>Geen gebruikers aanwezig</td>
      </tr>
   <? endif; ?>
</table>

En is dit dan weer overdreven ? :

PHP:

<?
// dingen uit DB halen, bewerken, etc

mysql_query(select bla bla

if...etc

// nu alles klaar

if (!empty($userlist)): 
       foreach ($userlist as $user): 
         include 'template_ding.tpl'; /*<tr><td><?=$user['name']?></td><td>*/
             if (!empty($user['avatar'])):
                include 'template_ding2.tpl'; /*  [img]"<?=$user['avatar']?>"[/img] */
               endif;
          include 'template_ding3.tpl';  /* </td></tr> */
   endforeach;
  else: 
      include 'template_ding3.tpl'; /*<tr><td>Geen gebruikers aanwezig</td></tr> */
endif;
include 'footer.tpl'; /* </table> */

Nu met dit voorbeeld kom je snel in de knoei (template files met slechts 1 regel html code erin). Merk nu zelf nu ik het uitwerk dat jouw (cheatah's) manier waarschijnlijk beter is, maar toch even posten

[ Voor 17% gewijzigd door We Are Borg op 25-01-2006 15:08 ]

[Anoniem: 26306]

We Are Borg schreef op woensdag 25 januari 2006 @ 15:08:

En is dit dan weer overdreven ? :
...
Nu met dit voorbeeld kom je snel in de knoei (template files met slechts 1 regel html code erin). Merk nu zelf nu ik het uitwerk dat jouw (cheatah's) manier waarschijnlijk beter is, maar toch even posten

Jij haalt de output van HTML die logisch gezien bij elkaar hoort (een rij met gebruikersnamen en eventueel usericons) uit elkaar. Dat zou ik niet doen. Je kunt wel eerst kijken of je wel gebruikers hebt (om weer te geven), en zo ja een template includen met de "foreach" erin. En een andere template als er geen gebruikers zijn.
Maar een aparte template voor een usericon is gewoon niet handig, tenzij je weer verschillende templates hebt waar in hetzelfde onderdeel in terugkomt. Ik zou de template bestanden in zo groot mogelijke "divisies" opdelen.

[Confusion]

BarôZZa schreef op woensdag 25 januari 2006 @ 13:18:
Gewoon wat witregels en een andere indeling zorgt al voor veel meer overzicht

Nou, van zoveel witregels word ik in ieder geval niet blij.

[Michali]

Anoniem: 43373 schreef op woensdag 25 januari 2006 @ 14:30:
[...]
Ja dat schiet op, mijn stukje code waarvan ik al aangeef dat ik het onoverzichtelijk vindt, vergelijken met Cheatah's code die gebaseerd is op mijn andere stuk code.

Ik refereerde alleen naar het stukje code dat je gaf. Ik heb helemaal geen uitspraak gedaan over hoe jij daar tegenover staat. Ik weet dat je het minder vind. Ik gebruikte het alleen als voorbeeld voor mijn punt

Ok, ik had ook naar het stukje code er boven kunnen refereren als verbetering, alleen vind ik die stijl toch iets minder. Ik preferreer alle php code op 1 regel te zetten, daarmee bedoel ik dat je naar en uit php modus gaat in 1 regel, zonder uitzonderingen.

PHP:

<!-- dus niet dit: -->
<?
if ( isset($vars) ) {
  foreach ( $vars as $var ) {
?>
    <html>
<? }
}
?>

<!-- maar dit: -->
<? if ( isset($vars ): ?>
  <? foreach ( $vars as $var ): ?>
    <html>
  <? endforeach; ?>
<? endif; ?>

Ten eerste is zo duidelijker wat PHP code is en wat HTML (een beetje progger ziet dat ook wel, maar toch lees het gemakkelijker). Bovendien is het schrijven van veel lappen PHP code zo moeilijker, wat je ook pushed om die code te verplaatsen. Ik maak zelf alleen uitzondering als ik recursieve functies oid maak. Omdat ik toch altijd met classes werk waarin ik de HTML render is het toevoegen van een functie goed in te passen. 3de argument voor de laatste is dat je veel makkelijk de foreach loop kunt vervangen met iets anders, je kunt hem in 1 keer weg knippen en ergens anders plakken, onafhankelijk van het if statement. Dat komt omdat je de php code eigenlijk gewoon als een speciale tag beschouwd.

[ Voor 62% gewijzigd door Michali op 25-01-2006 15:46 ]

[BarôZZa]

Confusion schreef op woensdag 25 januari 2006 @ 15:32:
[...]

Nou, van zoveel witregels word ik in ieder geval niet blij.

Ik doe het standaard voor en na elke if/while loop/etc. Dan zie je wat bij wat hoort.

Persoonlijke voorkeur uiteraard.

Al moet ik zeggen dat op moment van het proggen zelf m'n code vaak een teringzooi is en ik het om de 10-20 regels pas ff netjes opmaak.

[Michali]

BarôZZa schreef op woensdag 25 januari 2006 @ 16:11:
[...]

Ik doe het standaard voor en na elke if/while loop/etc. Dan zie je wat bij wat hoort.

Persoonlijke voorkeur uiteraard.

Al moet ik zeggen dat op moment van het proggen zelf m'n code vaak een teringzooi is en ik het om de 10-20 regels pas ff netjes opmaak.

Hoe bedoel je, dan zie je wat bij wat hoort? Als je gewoon normaal indent dan snapt iedereen dat. Bovendien kan een if statement logisch gezien bij enkele andere statements horen, als je er dan een witregel tussen plaatst werkt dat niet. Je moet zo min mogelijk wit regels gebruiken, alleen als je wilt aangeven dat 2 code blokjes logisch bij elkaar horen.

[BarôZZa]

Moet niet. Is persoonlijke voorkeur, voor de rest maakt het vrij weinig uit

ik vind

PHP:

if (bla)  
  echo "test";  
else
  echo "bla2";  
if (bla2)  
  echo "test2";  
else
  echo "bla3";  
if (bla3)  
  echo "test4";  
else
  echo "bla25";  
if (bla4)  
  echo "atest";  
else
  echo "bla2fwefe";

onoverzichtelijker dan

PHP:

if (bla)  
  echo "test";  
else
  echo "bla2";  

if (bla2)  
  echo "test2";  
else
  echo "bla3";  

if (bla3)  
  echo "test4";  
else
  echo "bla25";  

if (bla4)  
  echo "atest";  
else
  echo "bla2fwefe";

[Michali]

Dat vind ik ook. Al zul je zulke constructies zelden tegenkomen. Dat geeft ook aan waarom je meestal accolades moet gebruiken, omdat dit zaken onduidelijk maakt.

In het voorbeeldje, wat je in vorige post gaf, heeft het toevoegen van zoveel witregels geen enkel nut. Het rekt de code alleen uit.

[XWB]

BarôZZa schreef op woensdag 25 januari 2006 @ 17:39:
Moet niet. Is persoonlijke voorkeur, voor de rest maakt het vrij weinig uit

ik vind

PHP:

if (bla)  
  echo "test";  
else
  echo "bla2";  
if (bla2)  
  echo "test2";  
else
  echo "bla3";  
if (bla3)  
  echo "test4";  
else
  echo "bla25";  
if (bla4)  
  echo "atest";  
else
  echo "bla2fwefe";

onoverzichtelijker dan

PHP:

if (bla)  
  echo "test";  
else
  echo "bla2";  

if (bla2)  
  echo "test2";  
else
  echo "bla3";  

if (bla3)  
  echo "test4";  
else
  echo "bla25";  

if (bla4)  
  echo "atest";  
else
  echo "bla2fwefe";

En in zo'n geval vind ik een case nog overzichtelijker

[CH4OS]

Michali schreef op zaterdag 21 januari 2006 @ 12:06:
Zelf werk ik altijd op deze manier:

PHP:

<ul>
<? foreach ( $object->getWaardes() as $waarde ) { ?>
    <li><?=$waarde?></li>
<? } ?>
</ul>

Of een iets complexer voorbeeld wat meer php code vraag (die dus wel bij je presentatie hoort):

PHP:

function printFields($fields)
{
?>
  <ul>
  <? foreach ( $fields as $field ) { ?>
    <li>
      <?=$field['value']?>
      <? if ( count($field['childFields']) > 0 ) printFields($field['childFields']); ?>
    </li>
  <? } ?>
  </ul>
<?
}

printFields($data['fields']);

Dit is voor mij de meest effectieve manier gebleken. Iedere regel php code die tussen HTML staat begint met <? en eindigt met ?>. Als je veel van die regels naast elkaar hebt staan, dan is het beter om dat door de controller te laten opbouwen en bepalen. Je voegt dan een extra stap tussen het renderen in. Dat maakt de HTML code een stuk duidelijker en gemakkelijker aanpasbaar.

Deze manier lijkt mij nou ook niet bepaald goed om te werken... Ik geloof best, dat het voor jou het beste werkt, maar vergeet niet, dat nu elke keer PHP gestopt moet worden en dan weer gestart... Wat dus voor vertraging zorgt (ook al is het niet gigantisch veel). Plus dat dit (naar ik vernomen heb) meer geheugen in beslag neem...

Ik doe dan ook altijd de HTML in de PHP, dmv een echo of print... Maar ik laat wel de dingen die van te voren dienen te gebeuren, bijvoorbeeld content uit een database trekken, als eerste doen, het verzamelen van de content dus en daarna pas de content weergeven...

Ik lees overigens ook wel weinig mensen die gebruiken maken van ob_flush en dergelijke... Ik weet het niet 100% zeker, maar daarmee kan je toch output bufferen?

[Bosmonster]

GJ-tje schreef op woensdag 25 januari 2006 @ 18:38:
[...]
Deze manier lijkt mij nou ook niet bepaald goed om te werken... Ik geloof best, dat het voor jou het beste werkt, maar vergeet niet, dat nu elke keer PHP gestopt moet worden en dan weer gestart... Wat dus voor vertraging zorgt (ook al is het niet gigantisch veel). Plus dat dit (naar ik vernomen heb) meer geheugen in beslag neem...

Ik doe dan ook altijd de HTML in de PHP, dmv een echo of print... Maar ik laat wel de dingen die van te voren dienen te gebeuren, bijvoorbeeld content uit een database trekken, als eerste doen, het verzamelen van de content dus en daarna pas de content weergeven...

Ik lees overigens ook wel weinig mensen die gebruiken maken van ob_flush en dergelijke... Ik weet het niet 100% zeker, maar daarmee kan je toch output bufferen?

De minimale winst lijkt me nogal zinloos (als die er al is, PHP hoeft uiteraard niet 'gestopt' te worden. Het continue concatenaten van strings lijkt me zwaarder!), als het gaat om een betere scheiding van je code/html, leesbaarheid, onderhoudbaarheid, etc.

Wat output buffering met deze hele issue te maken heeft is mij een raadsel

[Anoniem: 26306]

GJ-tje schreef op woensdag 25 januari 2006 @ 18:38:

Deze manier lijkt mij nou ook niet bepaald goed om te werken... Ik geloof best, dat het voor jou het beste werkt, maar vergeet niet, dat nu elke keer PHP gestopt moet worden en dan weer gestart... Wat dus voor vertraging zorgt (ook al is het niet gigantisch veel). Plus dat dit (naar ik vernomen heb) meer geheugen in beslag neem...

Die verschillen zijn sowieso maar minimaal. En daar ga je je pas druk om maken als je applicatie zoveel gebruikt wordt, dat de performance van de server er zwaar onder te lijden heeft. Ik geef meer om makkelijk kunnen coden / onderhoud plegen, dan om een piepklein beetje snelheid dat ermee te winnen is.

Ik doe dan ook altijd de HTML in de PHP, dmv een echo of print... Maar ik laat wel de dingen die van te voren dienen te gebeuren, bijvoorbeeld content uit een database trekken, als eerste doen, het verzamelen van de content dus en daarna pas de content weergeven...

Als je altijd of het een of het ander doet, ben je gewoon niet handig bezig. Je vergist je gigantisch. Er hoeft helemaal geen "PHP gestopt worden". Een document wordt ingelezen, in stukken opgedeeld (tokens), en uiteindelijk verschilt echo "bla" dus niet zoveel van ?>bla<? Verder gaat dit allemaal zo vreselijk vlug... wat tijd kost, is een databaseverbinding maken, een query doen, een grote array verwerken.

Ik lees overigens ook wel weinig mensen die gebruiken maken van ob_flush en dergelijke... Ik weet het niet 100% zeker, maar daarmee kan je toch output bufferen?

Ja, maar dat staat los van of en hoe je PHP als template engine gebruikt. Maar je kunt natuurlijk prima een module een stuk HTML laten bufferen, door ob_start (); en ob_get_clean(); te gebruiken. Op deze manier hoef je template/include niets daarvan te weten.

[.oisyn]

Hacku schreef op woensdag 25 januari 2006 @ 17:50:

En in zo'n geval vind ik een case nog overzichtelijker

Ik denk het niet, schrijf het maar eens uit.

GJ-tje schreef op woensdag 25 januari 2006 @ 18:38:
maar vergeet niet, dat nu elke keer PHP gestopt moet worden en dan weer gestart...

Onzin. Hoe komen mensen toch altijd bij dat soort aannames...

[ Voor 63% gewijzigd door .oisyn op 25-01-2006 18:55 ]

[Michali]

@GJ-tje:

Dat vraagt om een benchmark:

PHP:

<?php

$times = 100000;

$start = microtime(true);
print "<!--<ul>";
for ( $i = 0 ; $i < $times; $i++ )
{
    print "<li>" . $i . "</li>";
}
print "</ul>-->";
$end = microtime(true);

$printTime = $end - $start;

$start = microtime(true);
?><!--<ul><? for ( $i = 0 ; $i < $times; $i++ ) { ?><li><?=$i?></li><? } ?></ul>--><?
$end = microtime(true);

$htmlModeTime = $end - $start;

?>
print time: <?=$printTime?></br>
html mode time: <?=$htmlModeTime?>

Output:

print time: 0.507936000824
html mode time: 0.556339025497

Verschil is echt klein. Wat veel belangrijker is, is hoe onderhoudbaar je code is. Met print statements is het aanbrengen van wijzigingen en het opsporen van fouten een stuk lastiger. Pas als je echt met performance problemen kampt en geforceerd bent om er wat aan te doen, pas dan zou ik code gaan profilen en punten waar de performance hit ligt optimaliseren. Ik kan je daarbij zeggen dat het niet het outputten van de HTML is waar dat zal liggen.

// edit: Benchmark was niet eerlijk, even aangepast.

[ Voor 28% gewijzigd door Michali op 25-01-2006 18:56 ]

[CH4OS]

Michali schreef op woensdag 25 januari 2006 @ 18:52:
@GJ-tje:

Dat vraagt om een benchmark:

PHP:

<?php

$times = 100000;

$start = microtime(true);
print "<!--<ul>";
for ( $i = 0 ; $i < $times; $i++ )
{
    print "<li>" . $i . "</li>";
}
print "</ul>-->";
$end = microtime(true);

$printTime = $end - $start;

$start = microtime(true);
?><!--<ul><? for ( $i = 0 ; $i < $times; $i++ ) { ?><li><?=$i?></li><? } ?></ul>--><?
$end = microtime(true);

$htmlModeTime = $end - $start;

?>
print time: <?=$printTime?></br>
html mode time: <?=$htmlModeTime?>

Output:

[...]


Verschil is echt klein. Wat veel belangrijker is, is hoe onderhoudbaar je code is. Met print statements is het aanbrengen van wijzigingen en het opsporen van fouten een stuk lastiger. Pas als je echt met performance problemen kampt en geforceerd bent om er wat aan te doen, pas dan zou ik code gaan profilen en punten waar de performance hit ligt optimaliseren. Ik kan je daarbij zeggen dat het niet het outputten van de HTML is waar dat zal liggen.

// edit: Benchmark was niet eerlijk, even aangepast.

0,05 seconden is anders op zich nog wel redelijk veel verschil, zeker omdat je nu de enige was die het scriptje draaide, denk dat het wel anders zal zijn, als er bijv. 1000 requests van dezelfde file tegelijk zijn... Dus echt representatief vind ik dit (helaas) niet echt, alhoewel het natuurlijk ook al bij een single user request ook al verschil laat zien... Thnx voor de moeite in ieder geval

[.oisyn]

Zo'n benchmark zegt natuurlijk helemaal niets, als je de twee tests bijvoorbeeld omdraait zie ik bij mij dat de html mode time ineens sneller is
(en zie ook mijn edit in mijn vorige post)


PHP 4.4-04

PHP:

<?
$times = 10000; 

function gettime($v)
{
    $a = explode(" ", microtime());
    return $a[0] + $a[1];
}


$start = gettime(true); 
?><!--<ul><? for ( $i = 0 ; $i < $times; $i++ ) { ?><li><?=$i?></li><? } ?></ul>--><? 
$end = gettime(true); 
$htmlModeTime1 = $end - $start; 

$start = gettime(true); 
print "<!--<ul>"; 
for ( $i = 0 ; $i < $times; $i++ ) 
{ 
    print "<li>" . $i . "</li>"; 
} 
print "</ul>-->"; 
$end = gettime(true); 
$printTime = $end - $start; 

$start = gettime(true); 
?><!--<ul><? for ( $i = 0 ; $i < $times; $i++ ) { ?><li><?=$i?></li><? } ?></ul>--><? 
$end = gettime(true); 
$htmlModeTime2 = $end - $start; 

?> 
print time: <?=$printTime?></br> 
html mode time 1: <?=$htmlModeTime1?></br> 
html mode time 2: <?=$htmlModeTime2?></br> 

Output:

code:

print time: 0.854218959808
html mode time 1: 0.708875179291
html mode time 2: 0.925388813019

Go figure

[ Voor 86% gewijzigd door .oisyn op 25-01-2006 19:13 ]

[Michali]

Idd, enkele keren refreshen geven allemaal willekeurige outputs. Soms is de HTML mode sneller.

En het zijn 100000 rijen die uitgeprint worden. Dat zul je normaal nooit tegenkomen.

[ Voor 32% gewijzigd door Michali op 25-01-2006 19:15 ]

[.oisyn]

Daarom is het ook handig om dit gewoon te lezen, en je niet bezig te houden met nutteloze "optimalisaties" als echo vs. print, single quotes vs. double quotes en nog meer van dat soort kolder. Optimalisaties doe je door je server goed te configureren en in je code goede algoritmes te gebruiken.

[CH4OS]

DDemolition schreef op woensdag 25 januari 2006 @ 13:26:
Vaak vind ik voor het overzicht dit:

PHP:

<?
if (functie() == true)
    {
    doehetene();
    }
else
    {
    doehetandere();
    }
?>

fijner als dit met die {} haakjes:

PHP:

<?
if (functie() == true) {
    doehetene();
    }
else {
    doehetandere();
    }
?>

zal nog wel vastgeroeste VB stijl zijn bij me.

Ik zelf doe het als volgt, soort mengeling van de jouwe:

PHP:

<?php
    if($blahblah == true)
    {
        doehetene();
    }
    else
    {
        doehetandere();
    }
?>

Maar het ging nu niet over de manier van schrijven van PHP, het gaat er nu om, wat sommige mensen doen, HTML door de PHP heen, of vice versa, of nog weer anders... Ik gebruik overs bovenstaand manier, omdat je dan beter ziet wat er (als het ware) in de lus zit...

[PrisonerOfPain]

GJ-tje schreef op woensdag 25 januari 2006 @ 18:38:
Ik geloof best, dat het voor jou het beste werkt, maar vergeet niet, dat nu elke keer PHP gestopt moet worden en dan weer gestart

Beter lees je je even in over de basis van PHP. Ik meen me trouwens te herrinneren dat ik ergens gelezen heb dat er zowel in het geval van een 'echo' als uit PHP springen een T_ECHO token word gegeven aan de parser.

[Michali]

*Kuch*

PHP:

if ( $blabla == true )

is hetzelfde als

PHP:

if ( $blabla )

of je moet echt dit willen

PHP:

if ( $blabla === true )

dat is wel anders.

[Spleasure]

Of je doet:

PHP:

<?php $blahblah ? doehetene() : doehetandere(); ?>

Kleiner kan ik het niet maken, en ik vind dit nog best overzichtelijk

[Anoniem: 43373]

Spleasure schreef op woensdag 25 januari 2006 @ 20:10:
Of je doet:

PHP:

<?php $blahblah ? doehetene() : doehetandere(); ?>

Kleiner kan ik het niet maken, en ik vind dit nog best overzichtelijk

Handig als je altijd alleen maar scripts maakt waarin maximaal 2 dingen mogelijk zijn.

[Spleasure]

Anoniem: 43373 schreef op woensdag 25 januari 2006 @ 20:24:
[...]
Handig als je altijd alleen maar scripts maakt waarin maximaal 2 dingen mogelijk zijn.

Het ging hier over de beste programmeerstijl van de code van DDemolition. Ik wilde alleen maar laten zien wat een van de kortste manieren is

En dit kan natuurlijk ook nog:

PHP:

<?php
$cond1 ? ($cond2 ? ding1en2() : ding1enniet2()) : ($cond2 ? nietding1enwel2() : nietding1enniet2());
?>

maar dat is minder fraai

[ Voor 22% gewijzigd door Spleasure op 25-01-2006 20:45 ]

[PrisonerOfPain]

Spleasure schreef op woensdag 25 januari 2006 @ 20:43:
En dit kan natuurlijk ook nog:

De overtreffende trap:

PHP:

(
    ($X == 'y') &&
    (
        iets()
    )
)
||
(
    ($X == 'z') &&
    (
        watAnders()
    )
    ||
    (
        wederomAnders()
    )
);

[Michali]

offtopic:
Dit topic kan denk ik wel genomineerd worden als topic met de meeste offtopic reacties over verschillende onderwerpen.

[XWB]

.oisyn schreef op woensdag 25 januari 2006 @ 18:49:
[...]

Ik denk het niet, schrijf het maar eens uit.

Je hebt gelijk, ik dacht dat het om 1 variabele ging, mijn fout

[.oisyn]

PrisonerOfPain schreef op woensdag 25 januari 2006 @ 19:25:
[...]

Beter lees je je even in over de basis van PHP. Ik meen me trouwens te herrinneren dat ik ergens gelezen heb dat er zowel in het geval van een 'echo' als uit PHP springen een T_ECHO token word gegeven aan de parser.

Beter lees je je even in in de draad

PrisonerOfPain schreef op woensdag 25 januari 2006 @ 20:56:
[...]

De overtreffende trap:

PHP:

(
    ($X == 'y') &&
    (
        iets()
    )
)
||
(
    ($X == 'z') &&
    (
        watAnders()
    )
    ||
    (
        wederomAnders()
    )
);

Leuk bedacht, het lullige is dat wederomAnders() altijd wordt uitgevoerd als de functies iets anders returnen dan wat evalueert naar true (wat het geval is bij geen enkele return value)

In C++ kan dit wel, daar heb je de , (komma) operator waarbij alleen de laatste operand als het resultaat van de expressie gerekend wordt. Daar kun je het stukje "iets()" dus vervangen door "iets(), true", zodat ie niet de andere expressie gaat proberen

[ Voor 42% gewijzigd door .oisyn op 25-01-2006 21:57 ]

[BalusC]

Waarom zie ik veel mensen zoiets als het volgende doen

PHP:

echo "<table border=\"1\" cellpadding=\"2\" cellspacing=\"3\">";

in plaats van het volgende

PHP:

echo '<table border="1" cellpadding="2" cellspacing="3">';

Enfin, ik zet altijd html in php. Mijn teksteditor ondersteunt gewoon html highlighting binnen php en ik vind het niet onoverzichtelijk. Grote lappen HTML, ongeveer meer dan 5 regels elk, zet ik in een include, tenzij het al onder een function() valt.

[FragFrog]

BalusC schreef op donderdag 26 januari 2006 @ 07:09:
Waarom zie ik veel mensen zoiets als het volgende doen
[..]

Dunno, ik doe eigenlijk standaart

PHP:

echo "<table border='1' cellpadding='2' cellspacing='3'>";

als ik al dingen echo in PHP dat is.. Wat ik tegenwoordig eigenlijk niet meer doe, maar laten we niet die discussie opnieuw gaan voeren

_{Overigens is "<table border=1 cellpadding=2 cellspacing=3>" voor in ieder geval single-digit waardes ook valid HTML als ik me niet vergis}

[ Voor 46% gewijzigd door FragFrog op 26-01-2006 07:26 ]

[BalusC]

Het was ook maar een voorbeeld. En ik gebruik eigenlijk overal in de php single quotes, behalve voor de mysql queries. En ik ben gewend om dubbele quotes in HTML te gebruiken en dat is ook netter, het is gewoon 'standaard'

[[ash]]

BalusC schreef op donderdag 26 januari 2006 @ 07:09:
Waarom zie ik veel mensen zoiets als het volgende doen

PHP:

echo "<table border=\"1\" cellpadding=\"2\" cellspacing=\"3\">";

in plaats van het volgende

PHP:

echo '<table border="1" cellpadding="2" cellspacing="3">';

Enfin, ik zet altijd html in php. Mijn teksteditor ondersteunt gewoon html highlighting binnen php en ik vind het niet onoverzichtelijk. Grote lappen HTML, ongeveer meer dan 5 regels elk, zet ik in een include, tenzij het al onder een function() valt.

Waarschijnlijk omdat dubbel-ge-quote string meer escape characters herkent, zoals \n .
http://us3.php.net/manual...ypes.string.syntax.double

[Anoniem: 26306]

[ash] schreef op donderdag 26 januari 2006 @ 07:57:

Waarschijnlijk omdat dubbel-ge-quote string meer escape characters herkent, zoals \n .
http://us3.php.net/manual...ypes.string.syntax.double

Waar je meestal dus niets aan hebt als je HTML output. Alleen in HTML e-mails wil je wel regelmatig wat linebreaks hebben. Maar die krijg je vanzelf in de "template syntax" van PHP.

[BalusC]

[ash] schreef op donderdag 26 januari 2006 @ 07:57:
Waarschijnlijk omdat dubbel-ge-quote string meer escape characters herkent, zoals \n .
http://us3.php.net/manual...ypes.string.syntax.double

Heb je het zelf uitgetest?

[BarôZZa]

BalusC schreef op donderdag 26 januari 2006 @ 07:09:
Waarom zie ik veel mensen zoiets als het volgende doen

PHP:

echo "<table border=\"1\" cellpadding=\"2\" cellspacing=\"3\">";

in plaats van het volgende

PHP:

echo '<table border="1" cellpadding="2" cellspacing="3">';

Enfin, ik zet altijd html in php. Mijn teksteditor ondersteunt gewoon html highlighting binnen php en ik vind het niet onoverzichtelijk. Grote lappen HTML, ongeveer meer dan 5 regels elk, zet ik in een include, tenzij het al onder een function() valt.

Omdat je anders geen $vars kan gebruiken.

PHP:

$var="hoi";

echo "$var hoi";  // output: hoi hoi
echo '$var hoi'; // output: $var hoi 

Ik doe wel eens " in de html vervangen voor ' als ik in een luie bui ben. Ja het is lelijk, maar het werkt .

[DDemolition]

BarôZZa schreef op donderdag 26 januari 2006 @ 09:12:
Ik doe wel eens " in de html vervangen voor ' als ik in een luie bui ben. Ja het is lelijk, maar het werkt .

Of gewoon weglaten
dus geen

PHP:

echo "<div align=\"Right\">";
//maar
echo "<div align=Right>";

Niet echt storend voor de meeste mensen maar wel gevaarlijk als je bijvoorbeeld title="bla bla" hebt. De spatie wordt dan niet gezien

[ Voor 8% gewijzigd door DDemolition op 26-01-2006 09:17 ]

[BalusC]

BarôZZa schreef op donderdag 26 januari 2006 @ 09:12:
[...]

Omdat je anders geen $vars kan gebruiken.

PHP:

$var="hoi";

echo "$var hoi";  // output: hoi hoi
echo '$var hoi'; // output: $var hoi 

Juist daardoor maak je echo's onoverzichtelijk. En de meeste highlight functies werken hier niet op.

PHP:

echo 'blaat '.$var.' hoi';

is dan weer duidelijker.

[Bosmonster]

DDemolition schreef op donderdag 26 januari 2006 @ 09:17:
[...]

Of gewoon weglaten
dus geen

PHP:

echo "<div align=\"Right\">";
//maar
echo "<div align=Right>";

Niet echt storend voor de meeste mensen maar wel gevaarlijk als je bijvoorbeeld title="bla bla" hebt. De spatie wordt dan niet gezien

Dat is dus gewoon _fout_. De quotes zijn verplicht. Right moet trouwens met kleine letters.

[Anoniem: 26306]

Bosmonster schreef op donderdag 26 januari 2006 @ 11:03:

Dat is dus gewoon _fout_. De quotes zijn verplicht. Right moet trouwens met kleine letters.

In HTML syntax mogen attributen zonder quotes als ze alleen bestaan uit letters,cijfers,streepjes of (dubbele)punten. De waarde van het align attribuut is case-insensitive, maar sowieso is het align attribuut natuurlijk deprecated in 4.01.

Overigens is het natuurlijk wel extreem handig om jezelf aan te leren altijd quotes om attribute values te zetten, en zoveel mogelijk in lowercase te doen.

[ Voor 16% gewijzigd door Anoniem: 26306 op 26-01-2006 11:23 ]

[.oisyn]

BalusC schreef op donderdag 26 januari 2006 @ 07:09:
Waarom zie ik veel mensen zoiets als het volgende doen

PHP:

echo "<table border=\"1\" cellpadding=\"2\" cellspacing=\"3\">";

in plaats van het volgende

PHP:

echo '<table border="1" cellpadding="2" cellspacing="3">';

Omdat het door elkaar gebruiken van quotes er alleen maar inconsistenter op wordt. En single-quotes lossen ook niet al je problemen op, single quotes in strings moeten namelijk ook nog altijd escaped worden. Daarnaast heb je met double quotes meer escape sequences tot je beschikking (newline, tab, etc... output is niet altijd html ). Daarnaast wordt de double-quote variant in de meeste programmeertalen gebruikt en is het voor mij dus puur een kwestie van gewenning.

Afgezien van het feit dat ik html vrijwel nooit in strings zet aangezien dat meestal niet op die plek hoort (ik doe vrijwel altijd een scheiding van code en opmaak)

[BarôZZa]

BalusC schreef op donderdag 26 januari 2006 @ 09:41:
[...]
Juist daardoor maak je echo's onoverzichtelijk. En de meeste highlight functies werken hier niet op.

PHP:

echo 'blaat '.$var.' hoi';

is dan weer duidelijker.

I know, maar is meer typwerk.

[XWB]

Ik gebruik altijd single quotes. Daartussen kan ik dan zetten wat ik wil. Variabelen hou ik er altijd vantussen, wat voor mij overzichtelijker is:

PHP:

<?php
$var = 'Karel'; 
echo 'Ik heet ' . $var; 
?>

BarôZZa schreef op donderdag 26 januari 2006 @ 13:12:
[...]

I know, maar is meer typwerk.

Dat valt best mee, als je het gewoon bent stoor je je daar echt niet aan Iedere keer een \ moeten plaatsen vind ik persoonlijk nog lastiger.

[ Voor 51% gewijzigd door XWB op 26-01-2006 13:14 ]

[PrisonerOfPain]

.oisyn schreef op woensdag 25 januari 2006 @ 21:48:
Daar kun je het stukje "iets()" dus vervangen door "iets(), true", zodat ie niet de andere expressie gaat proberen

offtopic:
"iets()" kun je gewoon vervangen door "(iets() || true)" voor eenzelfde resultaat, dunkt mij

[ Voor 9% gewijzigd door PrisonerOfPain op 26-01-2006 14:06 ]

[.oisyn]

da's idd waar

[Wim-Bart]

Ik heb het nog anders aangepakt. Ik werk gewoon met objecten welke de hele HTML renderen voor mij. De objecten zijn eigenlijk een soort framework zoals bij Borland Delphi wordt gebruikt.
Een voorbeeldje:

PHP:

require_once('inlude/htmlframework.php');
$oMyApp= new Page('title');
$oMyApp->addmeta('refresh','500;index.hml');
$oMyApp->settype(HTML4_TRANSITIONAL);
$oMyApp->setstyle('bodystyle');

$oTable= new Table('tabelstyle');
$oTable->NewLine();
$oTable->NewColumn('cell1style');
$oTable->AddField('Hello World');
$oTable->NewLine();
$oTable->NewColumn();

$oTable2= new Table();
$oTable2->newline();
$oTable2->newcolumn();
$oTable2->AddField(htmlspan('kleurstyle','Hello another world'));

$oTable->AddTable($oTable2);
$oMyApp->AddTable($oTable);

// Grapje, 2e tabel nog een keer
$oMyApp->AddTable($oTable2);

unset($oTable2);
unset($oTable);

// Een formpje
$oForm= new Form(FORM_POST,'/index.html');
$oTable= new Table();
$oTable->NewLine();
$oTable->NewColumn();
$oTable->AddField('Naam:');
$oTable->NewColumn();
$oTable->AddField(FormTextInput('fieldstyle','ID','POST_NAAM','DummyValue'));
$oForm->AddTable($oTable);
unset($oTable);
$oForm->AddTextValidator('ID','Naam goed invoeren (0-32 letters)',0,32));

$oMyApp->AddForm($oForm);
unset($oForm);
$oMyApp->show();
unset ($oMyApp);

[Anoniem: 43373]

@ wim-bart: Dat is dus echt niet te volgen imo.
Je moet echt regel voor regel lezen om te zien wat je doet.

[ Voor 6% gewijzigd door Anoniem: 43373 op 27-01-2006 12:56 ]

[Mithrandir]

wim-bart > Noo! Is dat te lezen? Is dat te onderhouden door andere mensen? Kun je werkelijk alles doen wat je wilt? Is het overal duidelijk wat er gebeurt?

Volgens mij niet. Het lijkt mij een complete ramp als ik 't zou moeten onderhouden, of zelfs maar begrijpen wat er staat. Waarom heb je voor deze methode gekozen?

[Michali]

Idd, kun je ook iets als dit doen:

HTML:

<table summary="Dit zijn gegevens">
  <caption>Gegevens</caption>
  <thead>
    <th scope="row">ID</th>
    <th scope="row">Naam</th>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Karel</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Piet</td>
    </tr>
  </tbody>
</table>

Ik zou met object niet op zo'n laag niveau gaan werken. Direct HTML schrijven is net zo veel werk. Beter is om het concept dat je ermee wilt weergeven te identificeren en daarvan een object te maken.

[BarôZZa]

PHP:

$oTable= new Table(); 
$oTable->NewLine(); 
$oTable->NewColumn();

Is dus hetzelfde als <table><tr><td>?

Kijk als je nou vaak een table maakt en vervolgens automatisch een table laat genereren aan de hand van bijvoorbeeld een dubbele array, dan zou ik me daar iets bij kunnen voorstellen. Maar voor elke html-tag een aparte functie aanroepen?!