[PHP] Best practices

[Verwijderd]

Ik ben bezig met een include file waarlangs ik forms kan aanmaken. Ik heb een aantal vragen over best-practices in PHP. Ik vraag me af of er officiele regels hiervoor zijn, of dat het afhangt van je voorkeur.

PHP:

$choices .= '<label class="option">';
$choices .= '<input type="checkbox" ';
$choices.= 'class="'. _form_get_class('form-checkbox', $required, _form_get_error($name)) .'" ';
$choices .= 'name="edit['. $name .'][]" ';
$choices .= 'value="'. $key .'"'. (in_array($key, $values) ? ' checked="checked"' : '');
$choices .= attributes($attributes). ' /> '. $choice .'</label><br />';

//of

$choices .= '<label class="option">'.
  '<input type="checkbox" '.
  'class="'. _form_get_class('form-checkbox', $required, _form_get_error($name)) .'" '.
  'name="edit['. $name .'][]" '.
  'value="'. $key .'"'. (in_array($key, $values) ? ' checked="checked"' : '').
  attributes($attributes). ' /> '. $choice .'</label><br />';

// of doe jij het nog anders...?

En als je kijkt naar regel 5. Is het netjes om een short-hand if-statement te gebruiken als de else niets returned? Met andere woorden:

PHP:

(in_array($key, $values) ? ' checked="checked"' : '')

// of

if (in_array($key, $values)) {
  $output.= ' checked="checked"';
}

Hoe "breed" programmeer jij eigenlijk? Ik probeer nu een breedte van 80 karakters aan de houden, maar soms (zie regel 3 uit eerste codeblok) is het bijna niet te doen om daarbinnen te blijven. Toch doen veel open-source projecten dat wel. Wat zijn de argumenten om je wel / niet aan 80 chars te
houden?

Soms denk ik ook wel - waarom moeilijk doen. Als het er eenmaal staat en het werkt, dan hoef ik er toch niet meer naar om te kijken. Als als dat wel nodig is, dan kost het hooguit een minuut extra. Je krijgt dan (uit dezelfde include file) bijvoorbeeld zoiets:

PHP:

$element = '<input type="checkbox" class="form-checkbox" name="edit['.$name.']" id="edit-'.$name.'" value="'.$value .'"'.($checked ? ' checked="checked"' : '').attributes($attributes).'>';

[Verwijderd]

Voor één element zou ik meestal 1 regel gebruiken zoals je liet zien. Ik vind die short-hand if-statement netjes maar gebruik ik zelden omdat ik het 'vergeet' daardoor 'simpeler manier' doe aan hand van een extra variabele.

[Erkens]

Verwijderd schreef op maandag 13 augustus 2007 @ 22:35:
Je code is vatbaar voor HTML injection (als de server dit toelaat).

dat kan je niet zeggen adhv deze code

---

Zelf ben ik voor dit soort dingen (als ik geen template erbij gebruik) nogal een fan van (s)printf.

[Cartman!]

Er zijn geen officiele regels nee, hoe jij t wilt.
Deze manier of OOP of met een template engine...

[Verwijderd]

Zelf vind ik de short-hand if-statement errug irritant om te lezen, waardoor ik hem dus ook nooit gebruik.
Ik heb nu al met code waar ik een tijdje niet naar heb gekeken dat ik er 'effe in moet komen', maar als je zulke syntax gebruikt, lijkt het me helemaal irri...

[Xcalibur]

Ik genereer sowieso nooit HTML in m'n PHP, dus ik zou het sowieso anders doen
Ik geef wel de voorkeur aan de tweede variant in je eerste voorbeeld.

Shorthand if's gebruik ik voornamelijk bij het definieren van variabelen, waarbij je een lijstje krijgt met per regel dus 1 variabele.... in een proces gebruik ik vrijwel uitsluitend gewone if's, meestal volgt daar ook een blok code binnen de if of de else

[Verwijderd]

Erkens schreef op maandag 13 augustus 2007 @ 22:38:
[...]
Zelf ben ik voor dit soort dingen (als ik geen template erbij gebruik) nogal een fan van (s)printf.

Je bedoelt zoiets?

PHP:

$output = sprintf('<input type="checkbox" class="%s" name="%s" value="%s" %s>',
  _form_get_class('form-checkbox', $required, _form_get_error($name)),
  $key, (in_array($key, $values) ? ' checked="checked"' : '', 
  attributes($attributes)
);

Xcalibur schreef op maandag 13 augustus 2007 @ 23:05:
Ik genereer sowieso nooit HTML in m'n PHP, dus ik zou het sowieso anders doen

Maar er komt toch een moment in je PHP dat je HTML moet tikken? Of ze je alle html in templates? En hoe ziet dat (pseudo) een functie die een html checkbox genereert er bij jou uit?

[Possstema]

Verwijderd schreef op maandag 13 augustus 2007 @ 23:12:
[...]

Je bedoelt zoiets?

PHP:

$output = sprintf('<input type="checkbox" class="%s" name="%s" value="%s" %s>',
  _form_get_class('form-checkbox', $required, _form_get_error($name)),
  $key, (in_array($key, $values) ? ' checked="checked"' : '', 
  attributes($attributes)
);

[...]

Maar er komt toch een moment in je PHP dat je HTML moet tikken? Of ze je alle html in templates? En hoe ziet dat (pseudo) een functie die een html checkbox genereert er bij jou uit?

Ik tik ook nooit meer PHP en HTML in hetzelfde bestand. Maak dan ook geen website's meer zonder Smarty. Zo hou je perfect de code gescheiden, en stel dat je echt de HTML moet genereren met PHP ( bv een boom uitschrijven in een UL-LI lijst ) dan maak ik er een smarty functie voor.

[FragFrog]

Possstema schreef op dinsdag 14 augustus 2007 @ 00:17:
Ik tik ook nooit meer PHP en HTML in hetzelfde bestand. Maak dan ook geen website's meer zonder Smarty. Zo hou je perfect de code gescheiden, en stel dat je echt de HTML moet genereren met PHP ( bv een boom uitschrijven in een UL-LI lijst ) dan maak ik er een smarty functie voor.

Same here

Enneh, Smarty kan lijsten ed al prima zelf genereren hoor

HTML:

<ul>
  {foreach from=$array item=item}
    <li>
      {$item}
    </li>
  {/foreach}
</ul>

Als het gaat om display logic hoef ik maar heel zelden zelf plugins / codeblocks schrijven.

* FragFrog wacht nu op de reacties van mensen die PHP zelf al een template parser vinden

[Erkens]

FragFrog schreef op dinsdag 14 augustus 2007 @ 01:58:
* FragFrog wacht nu op de reacties van mensen die PHP zelf al een template parser vinden

Dan moeten die mensen maar eerst eens kijken hoe smarty werkt, aangezien deze de templates "compiled" tot normale PHP scripts
Echter ook met het gebruik van een template engine ontkom je niet aan het "probleem" van de topic starter.

PHP:

$element = '<input type="checkbox" class="form-checkbox" name="edit['.$name.']" id="edit-'.$name.'" value="'.$value .'"'.($checked ? ' checked="checked"' : '').attributes($attributes).'>';

Als je dit namelijk herschrijft naar bijvoorbeeld smarty code, dan zal er ongeveer hetzelfde staan namelijk

Al met al moet je er gewoon voor zorgen dat de code overzichtelijk is en eenvoudig te lezen, is het dat niet dan kan je natuurlijk overwegen om er wat comentaar bij te zetten, maar beter is het om de code anders te schrijven zodat het niet direct nodig is.

[Slagroom]

@FragFrog: Maar Smarty kan niet recursief (recursiveren?) en dat is nou net nodig voor het maken van bomen

[ Voor 19% gewijzigd door Slagroom op 14-08-2007 08:19 ]

[koli-man]

Ik heb zelf geen ervaring met Smarty, maar een simpele template parser die ook wel goed werkt is de template parser van PEAR.

http://pear.php.net/package/HTML_Template_IT


Met betrekking tot de short if statements. Ik weet dat in de meeste projecten, waar ik mij moest houden aan de coding guidelines. De "lange" if statements toch geprefereerd werden i.v.m. onderhoud, of als iemand iets aan het if statement wilde toevoegen. En dan wil je na een half uur compileren niet achter komen dat je het if statement net ff verkeerd en te snel gelezen had.

[ Voor 53% gewijzigd door koli-man op 14-08-2007 08:30 ]

[Erkens]

Slagroom schreef op dinsdag 14 augustus 2007 @ 08:17:
@FragFrog: Maar Smarty kan niet recursief (recursiveren?) en dat is nou net nodig voor het maken van bomen

Je kan altijd nog een custom functie maken binnen Smarty waardoor in principe niks onmogelijk is.

koli-man schreef op dinsdag 14 augustus 2007 @ 08:22:
Met betrekking tot de short if statements. Ik weet dat in de meeste projecten, waar ik mij moest houden aan de coding guidelines. De "lange" if statements toch geprefereerd werden i.v.m. onderhoud, of als iemand iets aan het if statement wilde toevoegen. En dan wil je na een half uur compileren niet achter komen dat je het if statement net ff verkeerd en te snel gelezen had.

Natuurlijk, maar als het slechts een boolean is die gechecked moet worden dan heeft de ternaire conditionele operator toch mijn voorkeur:

PHP:

$value = "";
if ($bool) {
    $value = " checked";
}
printf('<input type="checkbox" name="test"%s>', $value);

PHP:

printf('<input type="checkbox" name="test"%s>', ($bool?" checked":""));

[ Voor 56% gewijzigd door Erkens op 14-08-2007 08:54 ]

[BikkelZ]

Ik probeer mijn HTML (templates) zo veel mogelijk te ontdoen van logica, en al dat soort variabelen van te voren te bepalen. MVC is daar bijvoorbeeld een hulp bij.

[Verwijderd]

Inderdaad, maar ook in MVC moet je in de V-stage html mixen met php.
Hoe je het ook draait of keert, op een bepaald moment komen die twee samen...

[Slagroom]

Erkens schreef op dinsdag 14 augustus 2007 @ 08:48:
[...]

Je kan altijd nog een custom functie maken binnen Smarty waardoor in principe niks onmogelijk is.

Dat snap ik ook wel maar wat FragFrog liet zien was een standaard loop waarmee je standaard geen bomen mee kunt maken.

[BikkelZ]

Verwijderd schreef op dinsdag 14 augustus 2007 @ 10:54:
Inderdaad, maar ook in MVC moet je in de V-stage html mixen met php.
Hoe je het ook draait of keert, op een bepaald moment komen die twee samen...

Het heeft ook wel te maken met het feit dat HTML en PHP twee totaal verschillende dingen zijn die eigenlijk niet zo gek veel met elkaar te maken hebben. Althans niet zoveel als Java en Swing.

[BCC]

Volgens mij wil je dit altijd met een of andere formbuilder doen, dan beperk je het mixen tot een absoluut minimum. Levert leesbaardere code op en minder fouten / exploit mogelijkheden in de resulterende form. Het zo mixen is volgens mij nooit een good practice. Kijk bijvoorbeeld eens naar de Ruby on Rails formbuilder als voorbeeld.

[ Voor 49% gewijzigd door BCC op 14-08-2007 11:59 ]

[Chesta]

Hoe "breed" programmeer jij eigenlijk? Ik probeer nu een breedte van 80 karakters aan de houden, maar soms (zie regel 3 uit eerste codeblok) is het bijna niet te doen om daarbinnen te blijven. Toch doen veel open-source projecten dat wel. Wat zijn de argumenten om je wel / niet aan 80 chars te
houden?

Ligt eraan welke resolutie het beeldscherm heeft waar ik op werk Op 1680x1050 heb ik regels van 220 karakters. Lange regels boeien mij niet zo, ik vind het alleen vervelend als 1 ding over meerdere regels verspreid word.

Wat jij hebt gedaan op regel 3 vind ik niet mooi, voor de leesbaarheid vind ik het beter als je het hele <input> element in 1 keer doet, zo dus:

PHP:

<?php
$choices .= '<label class="option">';
$choices .= '<input type="checkbox" class="'. _form_get_class('form-checkbox', $required,form_get_error($name)).'name="edit['. $name .'][]" '. 'value="'. $key .'"'. (in_array($key, $values) ? ' checked="checked"' : '').attributes($attributes). ' /> '. 
$choices .= $choice;
$choices .= '</label><br />'; 
?>

Alleen in dit geval word regel 3 wel weer heel lang door al die functies Die lange regel kun je inkorten door die short-hand if-statement apart te zetten (of er een gewone if-statement van maken ):

PHP:

<?php

$sel = (in_array($key, $values) ? ' checked="checked"' : '');

$choices .= '<label class="option">';
$choices .= '<input type="checkbox" class="'. _form_get_class('form-checkbox', $required,form_get_error($name)).'name="edit['. $name .'][]" '. 'value="'. $key .'"'.$sel .attributes($attributes). ' /> '. 
$choices .= $choice;
$choices .= '</label><br />'; 
?>

En als je kijkt naar regel 5. Is het netjes om een short-hand if-statement te gebruiken als de else niets returned? Met andere woorden:

Ja Sommige programmeurs gebruiken geen short-hand if-statements. Als ze een else zonder output hebben doen ze vaak dit:

PHP:

<?
if($blaat == "w00t") echo "1337";
?>

Dan vind ik het netter om een short-hand if-statement te gebruiken

[Erkens]

BCC schreef op dinsdag 14 augustus 2007 @ 11:56:
Volgens mij wil je dit altijd met een of andere formbuilder doen, dan beperk je het mixen tot een absoluut minimum. Levert leesbaardere code op en minder fouten / exploit mogelijkheden in de resulterende form.

Waarin verschilt een template engine van een "formbuilder"? Daarnaast moet die formbuilder ook geschreven zijn, hoe doe je het daar dan? Moet dat niet leesbaar zijn

offtopic:
over minder fouten/exploit mogelijkheden valt weinig te zeggen aangezien dat afhankelijk is van de situatie

Het zo mixen is volgens mij nooit een good practice.

"nooit" is wel een heel groot woord, er zijn altijd situaties te bedenken waar het wel eens anders kan zijn

[Verwijderd]

BCC schreef op dinsdag 14 augustus 2007 @ 11:56:
Volgens mij wil je dit altijd met een of andere formbuilder doen, dan beperk je het mixen tot een absoluut minimum. Levert leesbaardere code op en minder fouten / exploit mogelijkheden in de resulterende form. Het zo mixen is volgens mij nooit een good practice. Kijk bijvoorbeeld eens naar de Ruby on Rails formbuilder als voorbeeld.

Nou, de code uit de TS moet dus uiteindelijk mijn formbuilder include worden. In de rest van de code roep ik straks aan:

PHP:

$form.= form_checkbox('Signature?', 'signature', 'Ja');

// ala checkbox om Signature in te voeren bij plaatsen van een bericht op GoT

[Verwijderd]

Hap hap

[b][message=285544
Dan moeten die mensen maar eerst eens kijken hoe smarty werkt, aangezien deze de templates "compiled" tot normale PHP scripts

En wat maakt het 'compileren' van een intermediate bestand iets meer een template engine dan het ander?

[BikkelZ]

Nou ja een formbuilder kun je natuurlijk weer makkelijker integreren met het M-gedeelte van MVC. Ik zelfs wel eens met de gedacht gespeeld om een formulier uit te laten mappen aan de hand van wat SQL eigenlijk aangeeft wat voor veld het is, bijvoorbeeld checkbox bij TINYINT, een automatisch gepopuleerde pull-down aan de hand van een bepaalde JOIN die je aangeeft, allemaal dat soort grappen.

Je zou het zelfs nog verder door kunnen trekken door een user defined data type (niet in MySQL helaas) te gebruiken, bijvoorbeeld EMAIL of ZIPCODE. Dan wordt eigenlijk de opbouw van je formulier zo'n beetje bepaald door wat voor SQL velden je gebruikt, en kun je de controle in de PHP en JS lagen daarop afstemmen.

Een minder rigide oplossing is door aan te geven wat voor kolom het is, wat voor een soort veld (check, radio, pull-down, text, etc) het is en wat de standaard waarde is (alleen bij Create acties).

[Erkens]

Verwijderd schreef op dinsdag 14 augustus 2007 @ 12:58:
En wat maakt het 'compileren' van een intermediate bestand iets meer een template engine dan het ander?

Dat zeg ik niet. Echter als mensen zeggen dat je geen template engine moet gebruiken omdat PHP zelf die functionaliteiten al heeft zonder dat ze kijken hoe deze template engines werken dan is hun argument nogal loos. Aangezien smarty (als voorbeeld) van de makkelijkere/veiligere template code normale PHP code van maakt waardoor er nagenoeg geen verschil is uiteindelijk.

[MueR]

Verwijderd schreef op dinsdag 14 augustus 2007 @ 12:58:
En wat maakt het 'compileren' van een intermediate bestand iets meer een template engine dan het ander?

Ik heb liever dat een designer in een losse template zit te werken, dan dat hij rechtstreeks in mn source zit te klieren. Daar kan een stuk minder in kapot gemaakt worden, dus is het qua onderhoud een stuk gemakkelijker. Daarbij is het scheiden van HTML en PHP mijns inziens ook qua leesbaarheid een stuk beter.

[ATS]

BikkelZ schreef op dinsdag 14 augustus 2007 @ 12:59:
Nou ja een formbuilder kun je natuurlijk weer makkelijker integreren met het M-gedeelte van MVC. Ik zelfs wel eens met de gedacht gespeeld om een formulier uit te laten mappen aan de hand van wat SQL eigenlijk aangeeft wat voor veld het is, bijvoorbeeld checkbox bij TINYINT, een automatisch gepopuleerde pull-down aan de hand van een bepaalde JOIN die je aangeeft, allemaal dat soort grappen.(check, radio, pull-down, text, etc) het is en wat de standaard waarde is (alleen bij Create acties).

Dat lijkt mij nu juist weer géén aan te bevelen practice. Je maakt je hele applicatielogica afhankelijk van de datastorage layer. Dat lijkt me niet slim. Die zou ik juist lekker apart houden, en het geheel onafhankelijk van je datastorage layer houden. Zodadelijk moet je migreren naar een andere database backend (om wat voor reden dan ook), en kan je je complete applicatie opnieuw gaan zitten ontwerpen in plaats van alleen de datalayer aan te passen.

[BikkelZ]

Als je van plan bent om geen SQL meer te gaan gebruiken ben je wel het haasje. Anders kun je net zo goed het gebruik van SQL-queries af gaan schaffen, omdat je misschien naar XML of flat files migreert.
Maar het is een beetje een kip en ei verhaal hoor, want als je gaat migreren terwijl je veel gebruik maakt van views of stored procedures en je gaat naar een platform wat dat niet of anders implementeert ben je eigenlijk ook al afhankelijk.

Mijn filosofie is altijd dat een database daar waar mogelijk de data zo compleet mogelijk in een keer aflevert in het vereiste formaat via van te voren strak bepaalde paden. Views, stored procedures, etcetera in plaats van via een root user losse sql queries uit te voeren.

User defined types kunnen weer helpen om aan de ene kant beter foutieve data op databaseniveau af te vangen en anderszins duidelijker aan de buitenwereld te communiceren wat je precies voor een data hebt en verwacht als input. EMAIL(250) is duidelijker dan VARCHAR(250) terwijl je in allebei het zelfde op kunt slaan.

[Janoz]

@bikkelz

Een dergelijke stricte koppeling met de database vind ik een typische DBA-er benadering. Ikzelf werk meer vanuit een model. Dit model heeft vervolgens de (definierende) functie die jij aan de database toewijst. Het is (itt in de dababase) in code de normaalste zaak van de wereld om eigen types te definieren. Om naar formulieren te gaan heb je mappings voor formulieren (Die voor het grootste deel dynamisch kunnen werken). De database kan vervolgens uit dit model gegenereerd worden, maar er kan ook een mapping gemaakt worden op deen bestaande databron. De applicatie is dan niet te sterk aan de database gekoppeld (dat je formulier validatie afhankelijk is van het bestaan van een email type in de DB bv)

Het veranderen van je datasource is verder helemaal niet zo exotisch als dat je nu doet voorkomen. Wat nu als je toch een singe sign on wilt hebben waarbij verschillende user credentials uit 1 storage moeten komen? Wat nu als het bedrijf fuseert en de data van beide bedrijven moet worden gemigreerd?

Mijn voorkeur gaat dan uit naar het aanpassen van de mapping zodat het hele model gemapt kan worden op de nieuwe situatie. Voor de rest van de applicatie maakt het vervolgens niet uit of de data uit de andere database, de bestaande of zelfs via webservices opgevraagd wordt. De interface naar de datalayer blijft gewoon gelijk.

Natuurlijk is dat in jouw situatie ook wel mogelijk, maar dan handel je alles op database niveau af. Op de nieuwe database structuur maak je views die lijken op de oude situatie. Stored procedures werken nu ineens met een webservice ipv een select. Vandaar ook dat ik het de DBA benadering noem . Persoonlijk vind ik dat echter niet zo prettig werken. Ik ben dan ook geen DBA-er, maar een ontwikkelaar .

[BikkelZ]

Janoz schreef op dinsdag 14 augustus 2007 @ 16:06:
@bikkelz

Een dergelijke stricte koppeling met de database vind ik een typische DBA-er benadering. Ikzelf werk meer vanuit een model. Dit model heeft vervolgens de (definierende) functie die jij aan de database toewijst. Het is (itt in de dababase) in code de normaalste zaak van de wereld om eigen types te definieren. Om naar formulieren te gaan heb je mappings voor formulieren (Die voor het grootste deel dynamisch kunnen werken). De database kan vervolgens uit dit model gegenereerd worden, maar er kan ook een mapping gemaakt worden op deen bestaande databron. De applicatie is dan niet te sterk aan de database gekoppeld (dat je formulier validatie afhankelijk is van het bestaan van een email type in de DB bv)

Het is in mijn opzicht ook niet verkeerd om op applicatieniveau te zeggen 'Dit is een checkbox en als hij gevinkt is heeft hij een waarde van 1' of wat abstracter aan te geven 'Dit is een booleanveld, doe wat je normaal ook doet met booleans'. Maar dan wordt je database ook weer afhankelijker van je applicatie, want in een VARCHAR(250) kan dan ook 'Ik hou van friet' staan als je applicatie dat niet afvangt, ondanks dat je de kolom 'emailadres' genoemd hebt.

Janoz schreef op dinsdag 14 augustus 2007 @ 16:06:
@bikkelz

Het veranderen van je datasource is verder helemaal niet zo exotisch als dat je nu doet voorkomen. Wat nu als je toch een singe sign on wilt hebben waarbij verschillende user credentials uit 1 storage moeten komen? Wat nu als het bedrijf fuseert en de data van beide bedrijven moet worden gemigreerd?

Ja maar als je je database ook weer meer als 'applicatie' ziet waarbij een heleboel op databaseniveau afgehandeld wordt (van speciale datatypes tot foreign key constraints) is deze vaak ook weer makkelijker in te passen naar een andere applicatie. Een viewtje aanroepen of een complete complexe query uit oude source naar nieuwe source overzetten heeft ook weer hele andere implicaties.

Janoz schreef op dinsdag 14 augustus 2007 @ 16:06:
@bikkelz

Mijn voorkeur gaat dan uit naar het aanpassen van de mapping zodat het hele model gemapt kan worden op de nieuwe situatie. Voor de rest van de applicatie maakt het vervolgens niet uit of de data uit de andere database, de bestaande of zelfs via webservices opgevraagd wordt. De interface naar de datalayer blijft gewoon gelijk.

Natuurlijk is dat in jouw situatie ook wel mogelijk, maar dan handel je alles op database niveau af. Op de nieuwe database structuur maak je views die lijken op de oude situatie. Stored procedures werken nu ineens met een webservice ipv een select. Vandaar ook dat ik het de DBA benadering noem . Persoonlijk vind ik dat echter niet zo prettig werken. Ik ben dan ook geen DBA-er, maar een ontwikkelaar .

Ja eigenlijk zou je het gewoon het beste - mits performance het toestaat - via beide methodes tegelijk moeten doen. Database vangt het af, applicatie vangt het af, op dusdanige wijze dat beiden correcte data opleveren als de andere laag het niet zou doen.

Dat je dus even stringent een model opzet op PHP niveau als op SQL niveau is dan misschien wel dubbelop, maar houdt het aan beide kanten wel enigszins flexibel door ook jouw kant van het verhaal af te vangen.

----------

Maar ik dwaal af

[Janoz]

BikkelZ schreef op dinsdag 14 augustus 2007 @ 16:56:
Het is in mijn opzicht ook niet verkeerd om op applicatieniveau te zeggen 'Dit is een checkbox en als hij gevinkt is heeft hij een waarde van 1' of wat abstracter aan te geven 'Dit is een booleanveld, doe wat je normaal ook doet met booleans'. Maar dan wordt je database ook weer afhankelijker van je applicatie, want in een VARCHAR(250) kan dan ook 'Ik hou van friet' staan als je applicatie dat niet afvangt, ondanks dat je de kolom 'emailadres' genoemd hebt.

Natuurlijk is alles afhankelijk. Wat ik in mijn verhaal aangeef is meer welk deel leiden is en welk deel volgt. Jij kiest voor een leidende database terwijl ik kies voor een leiden object model. Jij laat je applicatie 'genereren'uit het database model terwijl ik mijn database laat 'genereren' uit mijn applicatie danwel een mapping maak tussen mijn applicatie en een bestaande database/datasource.

Ja maar als je je database ook weer meer als 'applicatie' ziet waarbij een heleboel op databaseniveau afgehandeld wordt (van speciale datatypes tot foreign key constraints) is deze vaak ook weer makkelijker in te passen naar een andere applicatie.

Dat database als applicatie zien is nu precies wat ik bedoel met de DBA benadering. De DB is leidend en de applicatie zelf is niks meer dan een slim viewtje op die database (plat gezegd).

Een viewtje aanroepen of een complete complexe query uit oude source naar nieuwe source overzetten heeft ook weer hele andere implicaties.

Dat zie je verkeerd. Die complexe query zit helemaal niet in mijn applicatie. Er zitten helemaal geen queries in het model. Die queries zitten in het mapping gedeelte. Nieuwe of anders vormgegeven databron zorgt enkel voor een nieuwe mapping. De rest van de applicatie veranderd helemaal niks. Natuurlijk kan zo'n query omzetten lastig zijn, maar de impact beperkt zich tot de mapping.

[BikkelZ]

Janoz schreef op dinsdag 14 augustus 2007 @ 17:10:
[...]

Natuurlijk is alles afhankelijk. Wat ik in mijn verhaal aangeef is meer welk deel leiden is en welk deel volgt. Jij kiest voor een leidende database terwijl ik kies voor een leiden object model. Jij laat je applicatie 'genereren'uit het database model terwijl ik mijn database laat 'genereren' uit mijn applicatie danwel een mapping maak tussen mijn applicatie en een bestaande database/datasource.


[...]

Dat database als applicatie zien is nu precies wat ik bedoel met de DBA benadering. De DB is leidend en de applicatie zelf is niks meer dan een slim viewtje op die database (plat gezegd).

Ja het komt dan veel sneller neer op een viewtje, al kan ik aan de andere kant op zich de pagina die we nu bekijken misschien ook eigenlijk wel tot een slim viewtje bestempelen. Waarbij een UBBCODE kolom meteen een leuk edit menuutje genereert of juist de UBBcode parst. Grootste probleem zit hem in het feit dat je steeds de informatie over je informatie eerst op moet halen uit de database. Twee queries in plaats van een.

Janoz schreef op dinsdag 14 augustus 2007 @ 17:10:
[...]
Dat zie je verkeerd. Die complexe query zit helemaal niet in mijn applicatie. Er zitten helemaal geen queries in het model. Die queries zitten in het mapping gedeelte. Nieuwe of anders vormgegeven databron zorgt enkel voor een nieuwe mapping. De rest van de applicatie veranderd helemaal niks. Natuurlijk kan zo'n query omzetten lastig zijn, maar de impact beperkt zich tot de mapping.

ORM is natuurlijk al een stuk minder SQL all over the place als pak 'em beet de gemiddelde OSCommerce installatie. Maar ik heb in de praktijk ook nog niet met mijn manier echt een projectje gedraaid, aangezien MySQL toch eigenlijk bijna onontkoombaar is bij PHP en het überhaupt niet ondersteunt.

[crisp]

Discussie over clientside coding practices afgesplitst naar Clientside coding underestimated of bijbaantje?

[BCC]

Even wat teruggehaald uit de afgesplitste thread

Waarin verschilt een template engine van een "formbuilder"? Daarnaast moet die formbuilder ook geschreven zijn, hoe doe je het daar dan? Moet dat niet leesbaar zijn

Dat doe je in dit geval in PHP en dat moet prima leesbaar zijn. Een Template engine is IMHO puur het invullen van variabelen in HTML. Natuurlijk kun je daar wat handige truuks bij doen (loops, equations, etc), maar volledige forms schrijven horen daar wat mij betreft niet bij.
Het toevoegen van bijvoorbeeld Ajax elementen aan je pagina valt daar IMHO ook onder. Je wil niet een bak javascript in je view hebben staan, maar je wil een php call die aan de hand van wat parameters fijne javascript output. Het kan wel, maar het is veel mooier om het te scheiden. Daarnaast wil je zelf helemaal geen javascript schrijven

Voorbeeldje van view in RoR (ja, daar is geen syntax highlighting voor op T.net):

PHP:

<?php
<h1><%= _('New purchase')</h1>
<%= error_messages_for :purchase %>
<div class="small_form_div"> 
<% form_for(:purchase, :url => purchases_path) do |f| %>
  <p>
    <b>Option</b><br />
    <%= f.collection_select :option, PurchaseOption.find(:all), :id, :name %>
  </p>
  
    <p class="buttonContainer">
      <%= submit_tag _('Create') %>
    </p>
<% end %>

</div>
?>

n de template vul ik dus wel bijvoorbeeld de vertaling van purchases in, maar de constructie van het formulier laat ik over aan de formbuilder. Bijvoorbeeld PHP Cake gebruikt dit soort constructies.

over minder fouten/exploit mogelijkheden valt weinig te zeggen aangezien dat afhankelijk is van de situatie

Ben ik het niet met je eens. Op het moment dat je voor elke edit-view een form script in je template schrijft, neemt de kans op een foutje enorm toe ten opzichte van een formbuilder die je overal gebruikt. En als je een lek/bug vind, kun je in 1x je volledige applicatie patchen.

Op het moment dat bijvoorbeeld XForms mainstream worden, heb ik met 1 patch mijn volledige applicatie gefixt.

[ Voor 5% gewijzigd door BCC op 15-08-2007 08:37 ]

[FragFrog]

Tja, ieder z'n eigen voorkeur. Ik gebruik zelf doorgaans een statisch javascript document wat in een common folder binnen mijn templatefolder staat. Op die manier kunnen alle templates van detzelfde javascript functies gebruiken maken, en clutter je niet je template met script. Ook wel eens gewerkt met door PHP gegenereerde javascript, maar die paar dingen die je variabel in je script moet hebben kun je wel efficienter doorgeven in mijn opinie

AJAX javascript gebruik ik de SAJAX toolkit voor, die wordt dan wel weer dynamisch gecreerd en geef ik mee als template variabele. Zou in principe ook wel anders kunnen (een script includen bijvoorbeeld, werk toch altijd met mod_rewrite) maar op zich vind ik een {$sajax_script} variabele niet lelijk staan - sowieso cache ik zoveel mogelijk en scripts laten zich prima cachen, dus meestal wordt m'n complete header inclusief ajax toch maar eens in de zoveel requests aanroepen, dat gaat een stuk simpeler door de ajax code als template var mee te geven dan zelf moeilijk te gaan doen

As for forms, daar zou ik eigenlijk ook nog wel een 'hippere' manier voor willen. Formbuilders klinken interessant, wellicht eens tijd dat ik me er in ga verdiepen

[BikkelZ]

Het Google JavaScript framwork werkt met een aantal specifieke meta-tags en een bootstrapper, dat vond ik niet helemaal perfect maar toch best wel een goede oplossing wat betreft het inladen van JavaScripts. Je geeft gewoon mee welke JavaScripts je met welke parameters wilt aanroepen en dat parse je keurig netjes op een plaats in je pagina.

Het voordeel van een formbuilder gebruiken is natuurlijk ook dat je applicatie veel bewuster is van welke form-elementen er zich allemaal op je pagina bevinden, want al die informatie moet ook weer allemaal gepost, gecheckt en verwerkt worden. Eigenlijk door het los in HTML te doen via een template doe je dubbel werk, omdat je zowel de fysieke inputs moet creeren als de verwerking van de gesubmitte informatie weer moet instellen.

[Verwijderd]

Nooit gedacht dat een simpele vraag tot zo'n discussie zou leiden

Ik onderbreek deze high-end discussie even voor een eenvoudige vraag. Stel dat ik een functie heb gemaakt waarlangs ik een textarea kan aanmaken. Ik wil de functiecall zo eenvoudig mogelijk houden:

PHP:

$title = 'Typ uw bericht';
$name  = 'message';
$value = 'dit is een ingeladen bericht';

$form.= form_textarea($title, $name, $value, 
  array('wrap' => 'virtual', 'class' => 'editor')
);

De uitvoer zou dan zoiets zijn:

HTML:

<div class="form-item">
  <textarea class="form-text" name="q[message]" class="editor" wrap="virtual">
    Dit is een ingeladen bericht
  </textarea>
</div>

Zoals ik hem nu het, accepteert form_textarea 4 parameter: title, name, value (allen strings) en attr (array). Die attr-array bevat properties die niet noodzakelijk zijn, zoals het definieren van een class.

Nu kan ik er ook voor kiezen om de hele input in een array te stoppen:

PHP:

$form.= form_textarea(array('title' => $title, 'name' => $name, 
  'value' => $value, 'wrap' => 'virtual', 'class' => 'editor')
);

Dit is meer uniform en misschien wel logischer, maar de funcie-call van een eenvoudige textarea gaat wel meer ruimte in beslag nemen. En ik heb toch graag zo min mogelijk code nodig om iets te bereiken:

PHP:

$form.= form_textarea(array('title' => $title, 'name' => $name, 
  'value' => $value)
);

// in plaats van ...

$form.= form_textarea($title, $name, $value);

Zijn er richtlijnen voor in welke vorm je parameters aan een functie moet doorgeven (dus: alles in array of losse parameters)? Wat zijn de eventuele voor- / nadelen van deze twee manieren?