[PHP] Graag mening over manier om applicatie te bouwen

[Reveller]

Als hobby maak ik mijn eigen CMS'je. Dat het maar voor mijzelf is wil niet zeggen dat ik het niet zo goed mogelijk wil doen. Ik wil de code zo onderhoudsvriendelijk mogelijk maken. Bovendien moet het systeem uit te breiden zijn.

Heel beknopt werk ik nu als volgt: ik

• include alle modules die ik heb
• lees de url uit en bepaal welke node uit de boom gevraagd wordt
• zoek uit aan welke module (artikel, gastenboek, ...) de node gekoppeld zit
• roep de module aan door [modulenaam]_init() aan te roepen

De reden dat ik eerst alle modules include is omdat ik niet weet of het verstandig is om ergens midden in je script een bestand te includen. Want logischer zou natuurlijk zijn om alleen de betreffende module te includen als ik uitgezocht heb welke module ik in moet laden:

• include_once 'modules/[modulenaam].php en dan
• roep de module aan door [modulenaam]_init() aan te roepen

Nu is het nog zo dat ik een module kan aanroepen en omdat deze al eerder geinclude is, kan de functie meteen gestart worden. Als ik "realtime" eerst de betreffende module moet includen, moet de rest van mijn script daarop wachten. Nu inlcude ik alles voordat ik verder script. Mijn vraag is of dit onzin is of is het inderdaad niet netjes om ergens midden in je script een afhankelijke include te doen?

Tweede vraag: als ik kijk naar opensource projecten als drupal.org, valt het me op dat deze software nooit "in de globale omgeving" (ik hoop dat ik me goed uitdruk) scripts draaien: letterlijk de hele applicatie bestaat uit functies die elkaar aanroepen. Alleen op index.php staat een stukje script wat niet in een functie zit. Alle andere bestanden bevatten alleen maar functies:

PHP:

// $Id: index.php,v 1.77 2003/12/16 21:06:33 dries Exp $

include_once "includes/bootstrap.inc";
drupal_page_header();
include_once "includes/common.inc";

fix_gpc_magic();

menu_build("system");

if (menu_active_handler_exists()) {
  menu_execute_active_handler();
}
else {
  drupal_not_found();
}

drupal_page_footer();

Is dat de beste manier van programmeren: om letterlijk alles in kleine en grote functies te stoppen? Soms komen hier op GoT hele lappen PHP code voorbij waarvan de code niet in een functie gestopt is. Wat zijn de voor / nadelen? Ik hoop dat ik duidelijk ben...

[Verwijderd]

functies komen van pas als je meerdere keren een stukje code nodig hebt om iets te doen. Het draagt natuurlijk ook bij aan de netheid/leesbaarheid van je code.

Het nadeel is wel dat als je functies wil gaan gebruiken voor meerdere dingen ze wel steeds complexer en complexer worden.

[Sybr_E-N]

De code die je voorgeschoteld krijgt op GoT zijn alleen maar de nuttige delen uit grote stukken code om o.a. het overzichtelijk te houden.

Door gebruik te maken van function's kun je je code opdelen in onderdelen. Welke je weer kunt gebruiken op het moment dat je ze nodig hebt. Zo kun je bepaalde stukken code vaker gaan gebruiken zonder dat je die code meerdere keren hoeft te schrijven.

[Reveller]

Sybr_E-N schreef op dinsdag 30 november 2004 @ 16:35:
Door gebruik te maken van function's kun je je code opdelen in onderdelen. Welke je weer kunt gebruiken op het moment dat je ze nodig hebt. Zo kun je bepaalde stukken code vaker gaan gebruiken zonder dat je die code meerdere keren hoeft te schrijven.

Ik ken het principe van functies, maar wat ik eigenlijk bedoel is: bij bijvoorbeeld drupal zie ik functies die eigenlijk alleen maar een stukje html returnen, verder niets. Wat is de reden om ook dat in functies te stoppen? Een voorbeeld:

PHP:

page_footer() {
  return '<table border="0" width="100%"><tr><td align="center">copyright
          ik</td></tr></table>';
}

[Creepy]

Is dat de beste manier van programmeren: om letterlijk alles in kleine en grote functies te stoppen? Soms komen hier op GoT hele lappen PHP code voorbij waarvan de code niet in een functie gestopt is. Wat zijn de voor / nadelen? Ik hoop dat ik duidelijk ben...

Meen je dit serieus? Wil je weten wat het logisch indelen van je code in functies / methods voor voor en nadelen heeft?

Als je dit echt vraagt dan raad ik je eens aan om een tutorial te zoeken hoe je code moet opzetten, hoe je code moet indelen, en hoe functies / methods werken. Dit is namelijk basis kennis die je echt wel moet hebben wil je goede, onderhoudbare code kunnen schrijven. Als je twijfelft of je je code logisch moet gaan opdelen dan kan ik, zonder naar je code te hebben gekeken, je nu al vertellen dat je code stukken netter en onderhoudbaarder kan zijn dat dat het nu is.

Edit: Die functie voor de footer is om makkelijk de footer aan te kunnen passen i.p.v. in een lap code te moeten gaan zoeken waar in hemelsnaam de footer staat

[ Voor 9% gewijzigd door Creepy op 30-11-2004 16:43 ]

[Verwijderd]

Wat reeds gezegd is: als je dat stukje HTML straks vaker nodig blijkt te hebben is het veel makkelijker om het in een functie te hebben zitten, in plaats van het te moeten copy/pasten elke keer. En als je het wilt veranderen, hoeft dat later maar op één plaats, in plaats van op alle plekken waar je de code had staan.

Ergo, code die (waarschijnlijk) vaker nodig is, lekker in een functie proppen. En het gebruik van functies en beschrijvende namen kan de logica die achter een stuk code zit duidelijker naar buiten laten komen, zoals jijzelf laat zien in je voorbeeld.

[creative8500]

Nooit in-code HTML!

[T-MOB]

Mwah.. die footer-functie vind ik ook overdreven. Je kunt ook gewoon een variabele $footer declareren met de inhoud van je footer. Desnoods, als je dit met meer stukjes html doet een array $components ofzo waar je dit soort stukken HTML in bewaart.

[Grijze Vos]

creative8500 schreef op dinsdag 30 november 2004 @ 17:05:
Nooit in-code HTML!

Tja, ik vind het juist netter. Vroeger was de verhouding html : php iets van 90 : 10 ofzo, tegenwoordig is de html output ondergeschikt aan de backend qua hoeveelheid, en is het logischer om de html juist wel in de code te zetten.

(Eventueel kun je natuurlijk je html in een lege file proppen en includen vanuit je php.)

[Michali]

Wat dacht je van Object geOrienteerd werken? Je bent zoals ik lees al bezig met een soort van procedurele polymorphisme, maar dat werkt met objecten heel wat gemakkelijker. Zeker met php5 erg dicht in de buurt zou ik dit toch overwegen. Kijk bijvoorbeeld eens naar de 'magische' functie __autoload. Deze dingen kunnen je programmer werk heel wat gemakkelijker maken

[ Voor 3% gewijzigd door Michali op 30-11-2004 19:32 ]

[Creepy]

creative8500 schreef op dinsdag 30 november 2004 @ 17:05:
Nooit in-code HTML!

Graag enige onderbouwing als je aan een discussie mee wilt doen.

[Verwijderd]

Wellicht is het volgende het overdenken waard. Het gaat niet zo zeer op voor php, maar voor programmeren in het algemeen. Ongetwijfeld ook in php, mijn php-kennis is nog maar beperkt.

Je hebt enerzijds data en anderzijds de look and feel. Nu wil je de look and feel door de tijd heen ongetwijfeld wel eens veranderen en dan is het practisch als je niet aan het gedeelte hoeft te komen wat de data oplevert.
Je wil dus functies die in eerste instantie de data vrij algemeen ophoest, zodat je daar later mee kunt bepalen hoe je dat wil presenteren (grafiek, circeldiagram, enz.)

Daarnaast moet je er van uitgaan dat je na enkele maanden al geen flauw idee hebt wat je hebt geprogrammeerd. Je bent immers al lang weer met iets anders bezig. Dan is het handig als dingen die vaak terugkomen een functie zijn met een duidelijke herkenbare naam. Daarnaast verdient het de aanbeveling om bij elke functie te zetten wat je er in stopt en wat je er uit krijgt. Dat maakt het later een stuk makkelijker om weer in je gedachtengang te komen.

Naast functies heb je ook attributen (variabelen) en samen kun je die ook weer bundelen in klassen. Voor die laatste stap biedt php beperkte ondersteuning die op zich wel de moeite waard is om nader te bekijken.

Denk ook na over persistente data en niet persistente data en of je je data wilt structureren in een database of bijvoorbeeld met behulp van XML.

Wellicht wil je de laatste twee alinea's nog even uitstellen.

edit: nog een kleine toevoeging. Het is handig om dingen die vaker gaan terugkomen, zoals een menu bijvoorbeeld vrij algemeen te maken. Zodat je later de boel (de menustructuur bijvoorbeeld) zonder al te veel te hoeven wijzigen kunt aanpassen naar een nieuwe site (bijvoorbeeld door de menustructuur in te lezen uit een xml-file oid).

[ Voor 11% gewijzigd door Verwijderd op 30-11-2004 18:56 ]

[Grijze Vos]

Verwijderd schreef op dinsdag 30 november 2004 @ 18:53:
Daarnaast verdient het de aanbeveling om bij elke functie te zetten wat je er in stopt en wat je er uit krijgt. Dat maakt het later een stuk makkelijker om weer in je gedachtengang te komen.

Naast formele correctheid heb je ook nog iets zoals plausibele correctheid, ook niet te onderschatten.

[Verwijderd]

Heeft hier niemand een linkje naar een website waar omschreven staat hoe en wanneer je bepaalde structuren gebruikt? Want ben ook van plan een (groot) project te beginnen. Ik ben er niet uit of ik met functies gaan werken (zoals tweakers). Of ik met XML ga werken. Of ik met DIV's ipv TABLE gaan werken enzoverder.

[Michali]

Verwijderd schreef op woensdag 01 december 2004 @ 18:40:
Heeft hier niemand een linkje naar een website waar omschreven staat hoe en wanneer je bepaalde structuren gebruikt? Want ben ook van plan een (groot) project te beginnen. Ik ben er niet uit of ik met functies gaan werken (zoals tweakers). Of ik met XML ga werken. Of ik met DIV's ipv TABLE gaan werken enzoverder.

Ik zou het hele verhaal van div. ipv. tables even hier volledig buiten laten. Wat ik je kan aanraden is altijd je applicatie logica te scheiden van je user interface. Of het nu een windows applicatie is of een php pagina. Hiervoor heb je verschillende goede mogelijkheden en gebruik van print statement in een functie is daar imo geen van. De opties die je imo het beste kunt toe passen zijn:

• Custom template parsen en invullen
• XML document opbouwen en XSLT template toepasen
• Variabelen of een assosiatieve array opbouwen en php zelf als template engine gebruiken (dmv. <?=$var?>, <? foreach ( $collectie as $item ) { ?> en <? if ( $bool ) { ?> statements gebruiken)

Persoonlijk vind ik de eerste niet de beste keus. Ten eerste geeft het parsen van een template overhead die je met de derde methode niet hebt, en je verliest de functionaliteit van de rest van php mocht je dit nodig hebben. Dat laatste punt geldt overigens ook voor de XML en XSLT combi. Als je al te maken hebt met XML data, zou ik zeker voor de tweede keus gaan. XSLT biedt een erg overzichtelijke en goede manier van opbouwen van een template mits goed toegepast. Ik ben het rijtje afgegaan zo als ik hem nu heb neergezet. Ik ben uiteindelijk toch aangekomen bij de laatste omdat geen parsen van een template omvat, je hoeft data niet moeilijk te gaan verpakken in een XML document, en php biedt erg fijne constructies voor het opbouwen van een template.

Een paar regels die ik hierbij altijd toepas zijn: geen print of echo statements (alleen <?=?> voor output van variabelen), geen logica tussen de HTML (behalve een simpel foreach, for, swith of if statement etc.) en geen puntkomma's (vrijwel ieder statement die eindigd met een puntkomma is beter te verplaatsen naar de pagina die de data ophaalt en de variabelen vult en <?=$var?> heeft geen puntkomma nodig) Als je deze regels aanhoudt zorg je dat het erg overzichtelijk blijft. Dat is voor mij de beste methode voor het toepassen van php zelf als template engine.

[Verwijderd]

Dank u voor de fijne uitleg. Zou je zo vrij willen zijn om is een voorbeeldje van een html/php file van jou hier te posten. Klein stukje is voldoende. Dat leerd beter omdat je dan iets voor ogen hebt.

[Creepy]

Een een klein stukje voorbeeld code heb je in dit geval niets. Structuren zijn nu eenmaal vrij abstract en ook zonder een stuk code wel redelijk uit te leggen.

Daarnaast zeg je dat je een project gaat beginnen maar je hebt denk ik geen idee hoe dat op te gaan zetten. DIV en TABLE's gebruik je voor de eventuele layout (als je al tables gebruikt XML kan je voor vanalles en nog wat gebruiken en functies of methods ga je hoe dan ook gebruiken in je code. Oftewel, je smijt met een paar termen maar ik krijg niet het idee dat je weet waar je over over praat.

Wat is er mis aan om met een klein project te beginnen zodat je vanzelf "leert" hoe je code in te delen? Wat is er mis met eens wat algemene boeken of tutorials te lezen over de opzet van code? En wat is er mis met het volgen van een opleiding om dit goed te kunnen doen? Hoe je het ook went of keert: ontwikkelen is een vak. De meesten van ons hebben dat echt niet geleerd door zelf maar wat te gaan prutsen en uitzoeken.

Met een fatsoenlijke informatica studie leer je naast de syntax van een taal ook hoe je je applicatie gaat opzetten, ontwerpen (niet alleen de GUI maar ook de binnenkant, en ja, dat heeft echt wel nut) en hoe je de uiteindelijke code moet gaan schrijven.

Dit is niet iets wat we je "even" kunnen laten zien in een klein stuk code of wat we je "even" kunnen uitleggen in een topic zoals dit. Daar is het dan weer te veel voor

[Bbfreak]

Dit zal altijd en voor iedereen anders zijn.
Wat ik persoonlijk erg belangrijk vind is dat je de code
en de weergave gescheiden houdt. Geef de designer geen code.
Bij kleine projecten zijn coder en designer misschien dezelfde
maar als dit niet zo is wil je dit toch gescheiden houden.
Als we bijvoorbeeld specifiek naar PHP kijken is Smarty
een zeer goed begin. Zorgt ten eerste voor performance verbetering maar zorgt
er ook voor dat de HTML code overzichtelijk is dmv templates en dat daar totaal
geen PHP code in voorkomt. Dit is al gebeurd voordat de template over de data wordt gelegd.
Ik hoop dat je hier wat aan hebt.

[Brakkie]

Als we bijvoorbeeld specifiek naar PHP kijken is Smarty
een zeer goed begin. Zorgt ten eerste voor performance verbetering maar zorgt
er ook voor dat de HTML code overzichtelijk is dmv templates en dat daar totaal
geen PHP code in voorkomt. Dit is al gebeurd voordat de template over de data wordt gelegd.
Ik hoop dat je hier wat aan hebt.

1. Smarty als template engine gebruiken an sich zorgt niet voor performance verbetering. Ten op zichte van sommige andere template engines is smarty misschien sneller omdat de templates gecompiled worden opgeslagen. Als je doelt op de caching feature in Smarty, je kunt je afvragen of dit een specifieke taak is van een template engine.
2. Er is in principe niets mis met PHP code in je HTML. Het hoofddoel is imo het scheiden van je business en programma logica van je HTML, niet het scheiden van je PHP code van je HTML. ( ps.: ga nou niet door over het nut van een template engine met een eigen syntax voor het printen e.d. van variabelen in de template, dat is al zooo vaak besproken.

[Verwijderd]

Snap het hele gebeuren rond templates niet. Kan iemand mij hier wat wijzer in maken?

Modbreak:

Als je een concrete vraag met betrekking tot programmeren hebt, open dan gewoon een nieuw topic. Ga hiervoor geen ander topic kapen

[ Voor 49% gewijzigd door Creepy op 02-12-2004 09:40 ]

[Bosmonster]

Creepy schreef op dinsdag 30 november 2004 @ 17:52:
[...]

Graag enige onderbouwing als je aan een discussie mee wilt doen.

Doe ik het maar voor hem:

Als je overal door je hele code heen stukjes html hebt staan wordt het nogal lastig om eens andere templates te gebruiken.

Over het algemeen wil je de presentatielaag (html) compleet scheiden van alle onderliggende code. Simpelweg voor beheerbaarheid, waar je zelf aan je topicstart te lezen zoveel waarde aan hecht.

Templates zijn een goed idee, maar als het toch alleen voor jezelf is (bijvoorbeeld backend templates voor het weergeven van het cms) kun je daar net zo goed PHP zelf voor gebruiken, wat per slot van rekening ook een template engine is.

Niet om de eeuwige template discussie weer op te starten, maar een zelfgebouwde template engine is weggegooide load als je de voordelen er niet van gebruikt. Een van de belangrijkste voordelen is de gebruiker beperken in zijn of haar mogelijkheden in de templates. Als een gebruiker zelf dus geen toegang heeft tot de templates is een zelfgebouwde template-engine nogal nutteloos, aangezien je dan net zo goed php als template taal kan gebruiken zoals het origineel bedoeld is.

M.a.w.: Geen html in code!!

[ Voor 23% gewijzigd door Bosmonster op 02-12-2004 10:03 ]

[jpwaag]

Michali schreef op woensdag 01 december 2004 @ 19:20:
[...]
is beter te verplaatsen naar de pagina die de data ophaalt en de variabelen vult en <?=$var?> heeft geen puntkomma nodig) Als je deze regels aanhoudt zorg je dat het erg overzichtelijk blijft. [...]

Het gebruik van <?=$sVar?> is niet aan te raden als je van plan bent je code te gaan gebruiken op servers waar je niet veel controle over hebt. Het is namelijk een optie in php.ini. Lang niet alle servers hebben dat aanstaan. Hetzelfde geld voor het gebruik van alleen <? in plaats van <?php.

[Creepy]

Bosmonster schreef op donderdag 02 december 2004 @ 10:01:
[...]
Doe ik het maar voor hem:
...

M.a.w.: Geen html in code!!

[Michali]

jpwaag schreef op donderdag 02 december 2004 @ 10:31:
[...]

Het gebruik van <?=$sVar?> is niet aan te raden als je van plan bent je code te gaan gebruiken op servers waar je niet veel controle over hebt. Het is namelijk een optie in php.ini. Lang niet alle servers hebben dat aanstaan. Hetzelfde geld voor het gebruik van alleen <? in plaats van <?php.

Dan vind ik dat een eis voor servers waar ik op ontwikkel. Het is geen probleem om dit even aan te passen. (het enige wat ik kan bedenken is dat je problemen krijgt met <?xml tags in xhtml of xml documenten, maar dat is ook wel op te lossen, door dit even te fixen)

[ Voor 3% gewijzigd door Michali op 02-12-2004 12:36 ]

[MaTriCX]

Conform de regels van software engineering schijnt het zo te zijn dat als je al je code in functies verplaatst, je de onderhoudbaarheid van je eigen applicatie vergroot.
Daarnaast is het ook de bedoeling dat je je functies toelicht met (pre- en postcondities en een beschrijving van de werking ervan), daarmee maak je je applicatie overdraagbaar.

Vooral bij open-source projecten is het van belang dat de geschreven stukken code makkelijk te implementeren, onderhoudbaar en overdraagbaar zijn. Maar als je er voor kiest om de applicatie geheel voor jezelf te houden en je liever werkt met HTML in je pagina's, dan moet je daar uiteraard voor kiezen. Ondanks dat het misschien niet helemaal voldoet aan de regeltjes, bevordert het wel het leesgemak en waarschijnlijk ook de snelheid waarmee je bugs kunt vinden..

[jpwaag]

MaTriCX schreef op donderdag 02 december 2004 @ 13:17:
[..]
Ondanks dat het misschien niet helemaal voldoet aan de regeltjes, bevordert het wel het leesgemak en waarschijnlijk ook de snelheid waarmee je bugs kunt vinden..

Dat denk ik niet hoor! Als er een fout zit in je html, waardoor de pagina niet juist weergegeven wordt, moet je door je code gaan spitten om de fout te vinden. Als je de html gescheiden had van je code dan scheelt dat voor het vinden van de fout. Zo ook bij fouten in je php code. Je hebt, als je de html niet direct in je code zet, meer overzicht over de code.

[Michali]

MaTriCX schreef op donderdag 02 december 2004 @ 13:17:
Conform de regels van software engineering schijnt het zo te zijn dat als je al je code in functies verplaatst, je de onderhoudbaarheid van je eigen applicatie vergroot.
Daarnaast is het ook de bedoeling dat je je functies toelicht met (pre- en postcondities en een beschrijving van de werking ervan), daarmee maak je je applicatie overdraagbaar.

Conform de regels van software engineering moet je ook je application en domain logica scheiden van je presentatie van de data. Het verplaatsten van zowel applicatie als presentatie code in een functie maakt je code zeker niet beter onderhoudbaar. Deze regel moet je dus ook maar in bepaalde context zien, en gaan in dit geval niet op. Uiteraard is het wel beter om bepaalde duidelijke taken te verdelen over aparte functies (en objecten als je OO werkt), maar als je met dit soort dingen al duidelijk rekening houdt, vind ik dat je de andere regels ook moet toepassen dan.

[Verwijderd]

MaTriCX schreef op donderdag 02 december 2004 @ 13:17:
Conform de regels van software engineering schijnt het zo te zijn dat als je al je code in functies verplaatst, je de onderhoudbaarheid van je eigen applicatie vergroot.

Alles massaal in zoveel mogelijk functies proppen is natuurlijk ook niet de oplossing. Je moet eerst begrijpen waarom dat zo is. Je houdt bijvoorbeeld de boundary-laag (grens-laag, datgene wat je ziet en bestuurd) gescheiden van de data-laag. Je zou er ook nog een control-laag in kunnen plaatsen, zodat je verschillende verantwoordelijkheden naar verschillende plaatsen van je applicatie kunt schuiven. Daar php niet zo super-OO is, betwijfel ik echter of dat met php ook te doen is (programmeer toch gewoon jsp ).
Dit maakt het allemaal erg overzicht en zeer geschikt om het later aan te passen. Je zou immers bijna geen code hoeven aan te passen als je iets toevoegd. Zeker als je met abstractie werkt, maar volgens mij ondersteund php inheritence nog niet zo.

Daarnaast is het ook de bedoeling dat je je functies toelicht met (pre- en postcondities en een beschrijving van de werking ervan), daarmee maak je je applicatie overdraagbaar.

klopt, maar je kan daarmee ook voor jezelf een beter beeld scheppen waarop je elke functie nu precies wilt testen (mits je elke functie afzonderlijk gaat testen _{weet niet of dat wel zo makkelijk gaat in php} )

Vooral bij open-source projecten is het van belang dat de geschreven stukken code makkelijk te implementeren, onderhoudbaar en overdraagbaar zijn. Maar als je er voor kiest om de applicatie geheel voor jezelf te houden en je liever werkt met HTML in je pagina's, dan moet je daar uiteraard voor kiezen. Ondanks dat het misschien niet helemaal voldoet aan de regeltjes, bevordert het wel het leesgemak en waarschijnlijk ook de snelheid waarmee je bugs kunt vinden..

Regels zijn over het algemeen voor eigen gemak opgesteld, anders zouden bedrijven al die regels al lang overboord gegooid hebben, want tijd is geld.
Overdragen doe je niet alleen aan anderen, maar ook aan jezelf. Als project A bijvoorbeeld is afgerond en je gaat door in project B, dan is het verdomd handig als je opeens nog iets in project A moet aanpassen, dat je het lekker overzichtelijk gebouwd hebt.

[Verwijderd]

En hoe houden jullie de html van de code dan gescheiden?
Maak je hier dan een template voor?
Of maak je functies die alleen html outputten?

[Bosmonster]

Verwijderd schreef op vrijdag 03 december 2004 @ 09:07:
En hoe houden jullie de html van de code dan gescheiden?
Maak je hier dan een template voor?
Of maak je functies die alleen html outputten?

Functies die html outputten is geen scheiding van html en code.

Templates is de enige manier om dat netjes te doen. Maar goed.. PHP = een template engine, dus erg ver hoef je niet te zoeken

[Creepy]

MaTriCX schreef op donderdag 02 december 2004 @ 13:17:
Conform de regels van software engineering schijnt het zo te zijn dat als je al je code in functies verplaatst, je de onderhoudbaarheid van je eigen applicatie vergroot.
Daarnaast is het ook de bedoeling dat je je functies toelicht met (pre- en postcondities en een beschrijving van de werking ervan), daarmee maak je je applicatie overdraagbaar.

Als je teveel hele kleine functies / methods / classes / units / whatever krijgt dan is je code zelfs minder onderhoudbaar Je zult hier echt een middenweg in moeten vinden

[Michali]

Ik vind het wel belangerijk dat een functie 1 belangerijke taak omvat, of dat nou 1 regel is of 10. Mocht ik binnen deze functie een extra duidelijk gescheide taak vinden, dan maak ik er hoe dan ook een extra functie van. Ik denk dat als je je aan de goede regels houd, dat je met veel functies duidelijkere code hebt dan met grote blokken. Natuurlijk moet je niet voor iedere regel code een functie gaan bouwen, dat is een beetje extreem, maar ik vind wel dat je een functie zo samenhangend mogelijk moet proberen te houden.

[Verwijderd]

Bosmonster schreef op vrijdag 03 december 2004 @ 09:49:
[...]


Functies die html outputten is geen scheiding van html en code.

Templates is de enige manier om dat netjes te doen. Maar goed.. PHP = een template engine, dus erg ver hoef je niet te zoeken

Ik denk dat ik me dan toch maar wat meer moet verdiepen in templates...

[Verwijderd]

edit:
^^^with stupid

Kortom, voor php (waar ik zelf bijna nooit in programmeer),lijkt het met het handigst om verschillende verantwoordelijkheden bij verschillende mappen te leggen, verschillende lagen (boundary, control, entity) bij verschillende bestanden, en verschillende taken bij verschillende functies?
Hoe dat dan met templates zit weet ik niet, want ik doe weinig echt websites bouwen, maar het lijkt me sowieso dus het handigst om eerst op papier te beginnen en niet gelijk in de code

[ Voor 4% gewijzigd door Verwijderd op 03-12-2004 10:36 ]

[Verwijderd]

Bosmonster schreef op vrijdag 03 december 2004 @ 09:49:
[...]


Functies die html outputten is geen scheiding van html en code.

Templates is de enige manier om dat netjes te doen. Maar goed.. PHP = een template engine, dus erg ver hoef je niet te zoeken

Hoe doe jij dat dan met tabellen die worden opgebouwd? Ik maak veel gebruik van een foreach loop of een while loop om data in tabellen te outputten, en ik geef hier nogal eens een css style aan mee. Hoe zorg jij dat er geen <tr><td></td></tr> in je functies komen, en hoe pas je dan de css toe?

[Verwijderd]

Michali schreef op vrijdag 03 december 2004 @ 10:07:
Ik vind het wel belangerijk dat een functie 1 belangerijke taak omvat, of dat nou 1 regel is of 10. Mocht ik binnen deze functie een extra duidelijk gescheide taak vinden, dan maak ik er hoe dan ook een extra functie van. Ik denk dat als je je aan de goede regels houd, dat je met veel functies duidelijkere code hebt dan met grote blokken. Natuurlijk moet je niet voor iedere regel code een functie gaan bouwen, dat is een beetje extreem, maar ik vind wel dat je een functie zo samenhangend mogelijk moet proberen te houden.

Het gebruik van functies moet je altijd goed aanpakken, alle acties die ik "algemeen" (universeel) uitvoer binnen mijn scripts krijgen functies. Denk aan een DatabaseClass/TemplateClasses ( TPL's bouw ik altijd adhv 2 Classes, de standaard replace class en een site-afhankelijke class ). Eigenlijk alles wat ik in meerdere scripts nodig heb staat verwerkt in classes.
Module afhangkelijke code (binnen een bepaalde functie van de website, bijvoorbeeld een Nieuws module, of een Image Gallery) die laat ik buiten mijn functies vallen. Het resizen van plaatjes doe je toch maar 1x binnen een website, en dat is tijdens het uploaden naar een de gallery. Dus zal ik het resize-script niet in een functie bouwen maar direct in de PHP Pagina.
Mocht het echter weer zo zijn dat ik op meerdere stukken binnen de site de image-resize nodig blijk te hebben dan maak ik daar wel een functie van.

Hoe kan je het beste commenten? Ik comment functies bijvoorbeeld op de volgende manier, en vind het erg prettig werken.

PHP:

//Functie ExplodeDataEx - Geeft een stukje terug adhv de gesplitte data
//Input:
// - 1, $data, string, exploded on "++"
// - 2, $needed, int, returned value
//Output:
// - $ret, string
//Example:
// - input: "1234++ABCD++0987+ZYXW", "2"
// - output: "ABCD"
function ExplodeDataEx($data,$needed) {
  $expl_data = explode($data,'++' ); //Explodes the data on ++
  $ret = $expl_data[$needed-1]; //Sets returnvalue

  return $ret; //Returns the data
}

Ook ben ik iemand die altijd ongeveer 25 witregels tussen belangrijke stukken code wil laten, zodat het een stuk leesbaarder is voor mezelf. Nou zou ik toch wel eens willen weten hoe andere mensen dit doen. Ik doe dit omdat ik anders die onderdelen tegen elkaar heb staan en door de grote (lees 200 a 300kb per module) die sommige onderdelen hebben binnen mijn scripts is dat echt nodig.
Voorbeeld:

PHP:

$blaat = geenidee();
//meer zooi voor de functies
//initialisatie enzo
//includen van alles

//hier de 50 witregels

if ($actie=='edit') {
  //de edit code
}

//25 witregels

elseif ($actie=='delete') {
  //de delete code
}

// 25 witregels

else {
  //de else code (meestal treeview van het onderwerp, soort list_topics idee)
}

//50 witregels

//het einde van de site
//construct_html uitvoeren, en meer dingen

[Verwijderd]

(...)25 witregels tussen belangrijke stukken code wil laten(...)hoe andere mensen dit doen(

Als ik het niet opsplits in nieuwe bestanden meestal zo:

PHP:

  endFunctionsiets;
}



/*************************************************************************************
*****************************NAAM NIEUW BLOK********************************
*************************************************************************************/


public niewFunction{

[Roeligan]

Kijk eens voor de gein op Fusebox.org Is ontwikkeld voor ColdFusion maar er zijn ook PHP soources aanwezig. Dit is een methodiek om generiek en modulair apps te bouwen.

[Michali]

Verwijderd schreef op vrijdag 03 december 2004 @ 10:35:
[...]


Hoe doe jij dat dan met tabellen die worden opgebouwd? Ik maak veel gebruik van een foreach loop of een while loop om data in tabellen te outputten, en ik geef hier nogal eens een css style aan mee. Hoe zorg jij dat er geen <tr><td></td></tr> in je functies komen, en hoe pas je dan de css toe?

Je kunt in je code waarin je de data ophaalt een multidimensionale assosiatieve array opbouwen welke je dan met behulp van loopjes in de template dan weer uitleest. Dat is toch niet zo'n probleem?

[Bosmonster]

Verwijderd schreef op vrijdag 03 december 2004 @ 10:35:
[...]


Hoe doe jij dat dan met tabellen die worden opgebouwd? Ik maak veel gebruik van een foreach loop of een while loop om data in tabellen te outputten, en ik geef hier nogal eens een css style aan mee. Hoe zorg jij dat er geen <tr><td></td></tr> in je functies komen, en hoe pas je dan de css toe?

Een template engine zoals PHP bevat naast het neergooien van wat variabelen ook control structures, oftewel loopjes, if statements, etc.

Zorg alleen dat je in je template zelf geen data ophaalt bijvoorbeeld, maar dat je dat alles vooraf doet en op een gestandaardiseerde manier data meegeeft aan de template.

[Michali]

Het beschikbaar zijn van alle kracht van php in de templates zefl is voor mij ook een van de grotere redenen dat ik deze methode gebruik. Het is namelijk niet te voorspellen wat je allemaal nodig zult hebben bij het bouwen hiervan. Mocht je dan toch beroep willen doen op enkele functies binnen php, dan heb je altijd de kans toe.