[PHP] Web-App best practices...classes, functies, MVC, etc

[maarud]

Waarschuwing: Lang, moeilijk verhaal

Ik zal als eerste even de situatie schetsen, dan weten jullie een beetje de achtergrond en de insteek van mijn verhaal cq topic

Ik mag graag digitale zaken bouwen. Het begon met mijn 'computerbedrijfje'. Ik wilde mijn klanten en werkzaamheden bijhouden om zo gestructureerd en professioneel te kunnen werken. Dit begon met het bouwen van een database in Access, maar omdat het van scratch opbouwen nog veel werk was in mijn beginjaren (geen IT-opleiding, alles zelf aangeleerd door uitproberen en een heleboel lurken op tweakers) heb ik de Northwind database gepakt en die een beetje getweaked.

Code van scratch opbouwen gaat niet zo snel, maar bestaande code lezen, begrijpen en ombouwen naar mijn wensen kan ik wel vrij snel. Die approach gebruik ik tot op de dag toe vandaag ook nog.

Ik zal nog even doorgaan op mijn inleiding. Die Northwind database werkte prima, behalve één ding: ik kon onderweg geen gegevens invoeren en/of er bij pakken. Dus: een webapp. Ook dat heb ik eerst van scratch geprobeerd, wat op zich redelijk lukte, maar codetechnisch zit het vast en zeker niet zo goed in elkaar.

Dus heb ik de voorbeelden van XAMPP (de muziek-collectiedatabase) gebruikt en omgebouwd naar mijn wensen, en zodoende geleerd hoe ik met SQLite en PDO om kon gaan, en ik kon gegevens lezen wen wegschrijven naar de database. Een vleugje AJAX en wat Responsive webdesign, en ik had een leuke web-app die goed werkte onderweg.

Afijn, aangezien ik blijf leren (in elke tutorial lees je wel eens wat moeilijke termen, en als ik die nazoek dan kom ik opeens in een heel ander niveau van PHP) kom ik ook steeds stapjes hoger.

Mijn volgende web-app was een soort mini-CMS, die werd al iets moeilijker door het inlezen van bestaande CMS-data en vervolgens uit te lezen en te manipuleren in mijn webapp, maar ook dat werkte.

Op een gegeven moment zag ik het woordje 'Bootstrap' en toen ik dat nazocht ging er weer een nieuwe wereld voor mij open. Tevens werden mijn website design-technisch ook opeens 100x zo mooi

Dus, nieuw projectje bedacht, weer van scratch begonnen (want ik wil mezelf elke keer overtreffen) en CMS 2.0 gemaakt. Zelfde functies als mijn eerste mini-CMS, maar PHP-technisch sterker. Ik las in een turoial over PHP functions en wéér ging er een wereld open, sterker nog, mijn code werd opeens ook overzichtelijker, haha. Waar ik alleen nog niet zo zeker over was is het volgende:

Alle 'actie-linkjes' (dus toevoegen van user, verwijderen van user, editen van user-data) POSTen hun data naar de respectievelijke 'actie-pagina's'. Dus, in mijn tabel met users staat achter elke user een potloodje en een prullenbakje, die linken naar /edit.php?type=user&id=1 of /delete.php?type=user&id=1.

De edit.php werd op een gegeven moment langer en langer, want naast users had ik ook contacts, adresses, enzovoort. Dus kreeg ik:

PHP:

if ($type=='user') {
//query dit en dat 
} elseif ($type=='contact') {
//query voor contacpersonen 
} //enzovoort

Voor mijn gevoel kon het nooit de bedoeling zijn dat ik straks eindig met ontzettend lange edit.php's vanwege alle if/else voor alle mogelijke uitkomsten, dus zocht ik verder.

Zo kwam ik na het lezen van veel tutorials en mijn favo-site StackOverflow een term tegen en zodoende weer in een hoger niveau terecht: OOP met z'n classes.
Man man man, dat was pas wat... in plaats van 4 dezelfde queries kon ik gewoon:

PHP:

$nummer1 = new OpzoekQuery();
$nummer2 = new OpzoekQuery();

doen. Dat scheelde pas een boel werk!

Dus, CMS 2.0 is gebouwd met een aantal classes en functies. Werkt al een heel stuk makkelijker en beter. Mijn login-systeem is op basis van PHPLogin en met behulp van die class heb ik ook mijn andere classes geschreven (hence het stukje uit mijn inleiding, ik ben goed in bestaande code aanpassen en gebruiken ).

In plaats van de edit.php en delete.php files post ik nu naar self want de pagina's met formulieren beginnen met

PHP:

$form = new form();

en in de class heb ik:

PHP:

class form {
    
    public function __construct()
    {        
        if (isset($_POST["add-user-submit"])) {
            //bla bla
    } 
}
}

Maar ook hier begint het te jeuken bij mij, want zo eindig ik op een gegeven moment ook weer met heel veel if/elseif voor alle mogelijke formulieren. Ik wil niet continu een extra functie blijven maken voor als ik weer iets nieuws verzien wat met een formulier toegevoegd kan worden.

Tot nu toe is dit allemaal een leuke leerschool geweest, alleen het probleem is dat ik elke keer iets aan het maken ben op de manier waarop ik tot dan toe denk: Dit is het!
Tot ik aan het eind van de rit nieuwe termen lees en denk: Oef...ik had het veel beter zo kunnen doen. Zo leer je natuurlijk, maar op een gegeven moment ben je daar ook wel klaar mee

Nu heb ik namelijk een hele tutorial over MVC achter de rug en waar ik net van af gestapt ben (edit.php?type=user&id=9) komt dan in zeker opzicht weer terug door de controllers en dergelijke.

Ik lees ook dingen over Frameworks, Symfony bijvoorbeeld. Maar dat vind ik nog best moeilijk, als ik die tutorial lees. Het gevoel wat ik daar bij krijg is: veel te veel mogelijkheden voor de simpele web-apps die ik bouw. Sterker nog, ik wil mijn eigen classes en functies maken om zo te kunnen blijven leren, al gaat een framework vast 10x zo snel.

Conclusie: Waar kan ik het het beste mijn aandacht op richten? Zoals je merkt spring ik wellicht van de hak op de tak (of zit er toch een bepaalde lijn in?) omdat ik natuurlijk nooit geleerd heb 'hoe het echt moet'. Vandaar de topic titel: Best practices. Natuurlijk heeft ieder zijn eigen voorkeur (wel of geen MVC, frameworks, etc) en hangt het van de web-app af.

Maar wat zou in het algemeen de best practice zijn voor een web-app waarin je vrij 'standaard' new, edit en delete-acties doet? Nieuwe users, nieuwe artikelen, nieuwe cd voor je cd-collectie, noem het maar op. Ik heb nu elke pagina zijn eigen hardcoded.php gegeven. Gelukkig heb ik wel een algemene header en een algemene footer om te voorkomen dat ik 25 files langs moet als ik iets in de header aanpas. Maar misschien zijn views ook wel wat, dan is er nog meer gestandaardiseerd.

Mijn doel is uit eindelijk om een 'echte' web-app op te zetten. Dus naast de standaard new, edit en delete acties ook settings en widgets. Nu zijn alle settings hard-coded en die wil ik op een gegeven moment ook via het web kunnen aanpassen. Ook daar zoek ik weer naar de 'beste' manier: Zoals dit, of dit.

Hoe krijg ik structuur in mijn zoektocht/leerschool? Zijn er mooie ebooks, tutorials of webinars die ik kan doornemen om te voorkomen dat ik versie 4.0, 5.0, 6.0 krijg en iets nooit af komt? En dan misschien met name de filosofie achter classes bijvoorbeeld? Ik heb het idee dat ik ze een beetje verkeerd gebruik cq misbruik. Maar dat kan ook komen omdat ik die PHP Login als basis gebruik om mijzelf classes aan te leren (en dus de __construct voor alles misbruik).

[Barryvdh]

Mijn mening:

Ga een MVC framework leren gebruiken. Ik zou kiezen voor Laravel, momenteel een van de populairste moderne frameworks.

Ook al ga je daarna iets anders gebruiken, dan snap je waarschijnlijk beter de ideeën achter Routing/Controllers (in plaats van edit.php?type..), Models/ORMs (in plaats van je eigen queries schrijven), Views/templates (in plaats van html echo'en), dependancy injection etc etc.

Heeft goede documentatie, moderne tools, actieve community en een aantal boeken.
En belangrijkste misschien wel Laracasts, met heel veel webcasts over Laravel, maar ook PHP, testen, design patterns, best practices ed.

[maarud]

Hmm, misschien dan toch maar de stap wagen en een framework onderzoeken. Die Laracasts zijn grappig idd, die zal ik gaan kijken

Wel iets compleet anders dan html echo'en inderdaad...ach, van scratch beginnen ben ik gewend

[Donderpoes]

Een framework kan je een hoop werk uithanden nemen, maar ik begrijp uit jouw verhaal dat je daar nu niet echt trek in hebt. Al zou het wel een goede leerschool zijn.

Waar je volgens mij nu al een paar keer tegen aan gelopen bent is dat je het wiel steeds opnieuw aan het uitvinden bent.
Je zal altijd nieuwe dingen blijven lezen, deze wereld is namelijk volop in beweging. Deze nieuwe dingen wil je misschien ook wel weer verwerken in je applicatie.

Vanuit dat oogpunt zou ik beginnen om je applicatie schaalbaar en in lagen op te bouwen.

Probeer de verschillende lagen van je applicatie te scheiden. Je output is op dit moment HTML, morgen heb je CSV output nodig en overmorgen XML.
Dat is niet zomaar te organiseren met HTML output. Je zou kunnen overwegen om alles bijvoorbeeld in JSON te outputten en daaromheen een laag te bouwen welke je output verwerkt naar HTML, CSV, XML, enz.
Je zou je data kunnen verwerken met bijvoorbeeld AngularJS of een PHP templating systeem als Twig.

Zo kan je verschillende lagen in een applicatie identificeren en eventueel alles van elkaar scheiden.
Maar denk goed na welke laag voor wat verantwoodelijk is.

Verder wil ik je wijzen op composer. Middels composer kan je makkelijk packages van derden installeren en ook het inladen van deze packages of andere bestanden die je zelf maakt kan composer je uit handen nemen.

[Biersteker]

maarud schreef op donderdag 07 mei 2015 @ 11:00:
Lang, moeilijk verhaal

Je zou een framework kunnen pakken zoals barryvdh zegt. (barry is wel enorm laravel fan ).
Maar wat misschien ook handig is, is ook wat meer van design patterns mee te nemen. Zelf vond ik dit wel een handige ( http://shop.oreilly.com/product/0636920028062.do ). Hoewel design patterns niet echt vast staan, en iedereen weer zijn eigen interpretatie aan geeft, is het wel handig om de verschillende manieren te hebben gezien. (factory, singleton, strategy design etc.)

[maarud]

Donderpoes schreef op donderdag 07 mei 2015 @ 11:54:
...

Ik vind inderdaad steeds het wiel opnieuw uit...daarom wil ik nu zorgen dat ik in ieder geval de techniek gebruik die 80% van de programmeurs gebruikt om dit soort websites te maken Maar goed, in principe gebruikt iedereen weer wat anders heb ik het idee, al is de basis in grote lijnen hetzelfde (framework, MVC, gescheiden dingen).

De data die opgehaald wordt uit de database (een overzicht van de personen bijvoorbeeld) wordt als JSON uitgespuugd en door DataTables verwerkt. Dus in zeker opzicht gebruik ik dat al deels.

Biersteker schreef op donderdag 07 mei 2015 @ 12:02:
[...]

Dat boek ga ik onderzoeken, thanks!

[Cartman!]

Een ander snel te leren framework is Silex en omdat t bouwt op componenten van Symfony kan het direct een opstap zijn naar full stack Symfony in het vervolg.

[Barryvdh]

Cartman! schreef op zaterdag 09 mei 2015 @ 20:00:
Een ander snel te leren framework is Silex en omdat t bouwt op componenten van Symfony kan het direct een opstap zijn naar full stack Symfony in het vervolg.

Maar in vergelijking met Laravel heeft Silex een stuk minder structuur en meer vrijheid. Kan goed zijn maar als je op zoek bent naar 'best practices' is meer structuur misschien beter, toch?

[Cartman!]

Barryvdh schreef op zaterdag 09 mei 2015 @ 20:17:
[...]

Maar in vergelijking met Laravel heeft Silex een stuk minder structuur en meer vrijheid. Kan goed zijn maar als je op zoek bent naar 'best practices' is meer structuur misschien beter, toch?

Laravel staat mij niet aan en ik ben juist gek op de vrijheid van Silex en de componenten van Symfony vind ik van veel hogere kwaliteit (niet voor niks gebruikt Laravel er inmiddels ook al een paar). Best practices hangen imo niet perse samen met een developer een hoek induwen waar je niet uit mag komen.

Neemt niet weg dat Laravel voor de TS een goede keuze kan zijn, smaken verschillen eenmaal dus ik geef er alternatief bij

[ Voor 9% gewijzigd door Cartman! op 09-05-2015 22:08 ]

[maarud]

Ik zit nu de afgelopen dagen het cookbook en de tour op symfony te lezen en ik wordt er helemaal blij van. Zoveel zaken die al voorgekauwd zijn en waar je op kan bouwen (duh! Haha). En al die bundles die je kan krijgen...zelfs een ldap auth bundle die ik handmatig in PHP probeerde te maken. Ik ga maandag even lekker aan de slag en een demo site maken om het onder de knie te krijgen, maar het spreekt me allemaal wel heel erg aan. Weer een hoger niveau bereikt......frameworks, orm (doctrine), twig... Best leuk allemaal!

[Amanush]

Barryvdh schreef op donderdag 07 mei 2015 @ 11:12:
[...]
Ga een MVC framework leren gebruiken. Ik zou kiezen voor Laravel, momenteel een van de populairste moderne frameworks.
[...]

Is er een reden waarom je een MVC framework zou moeten gebruiken?

[Barryvdh]

Amanush schreef op zondag 10 mei 2015 @ 20:50:
[...]

Is er een reden waarom je een MVC framework zou moeten gebruiken?

Je moet niets Maar TS is op zoek naar meer structuur, en MVC frameworks (en afgeleiden daarvan, want het is allemaal niet puur MVC) bieden daar een oplossing voor. Kan hij daarna zelf bepalen of hij dat wel of niet prettig vindt werken. Ik vind van wel iig

[Amanush]

Barryvdh schreef op maandag 11 mei 2015 @ 09:01:
[...]

Je moet niets Maar TS is op zoek naar meer structuur, en MVC frameworks (en afgeleiden daarvan, want het is allemaal niet puur MVC) bieden daar een oplossing voor. Kan hij daarna zelf bepalen of hij dat wel of niet prettig vindt werken. Ik vind van wel iig

Akkoord, maar op zich maakt het niet uit welk patroon de frameworks gebruiken, mits ze maar Seperation of Concerns toepassen.

[Xirt]

Mijn advies zou eigenlijk zijn om eerst eens een lijst met design patterns te bestuderen. Deze geven je een goed idee van 'best practices' die veel gebruikt worden binnen het programmeren (waaronder bijv. MVC). Kijk bijvoorbeeld eens op deze of deze website.

[DJMaze]

maarud schreef op donderdag 07 mei 2015 @ 12:08:
Maar goed, in principe gebruikt iedereen weer wat anders heb ik het idee.

Klopt als een bus!
Ik gebruik geen Laravel noch Symfony noch Smarty noch Zend noch Yii noch whatever.
Ben er achter gekomen dat de meesten gewoon veel te loch en zwaar zijn voor iets simpels als een website.
En vreemd genoeg gebruik ik toch mijn eigen REST framework.

Er is gewoon geen holy grale, gebruik waar je je prettig bij voelt.

Mijn set bestaat vooral uit RFC's, Zope TAL (in PHP) en ANSI/ISO SQL via MySQLi.

Daarnaast zijn al mijn bestanden lowercase omdat de php autoloader gewoon zo werkt, en het voorkomt problemen bij Windows ontwikkelaars die iets uploaden naar een UNIX systeem.
Snap niet dat er bijna geen een framework is dat hier rekening mee houdt.

[ Voor 17% gewijzigd door DJMaze op 12-05-2015 14:39 ]

[maarud]

Ik probeer nu in Symfony een stukje van mijn website te bouwen (gewoon een kopie van mijn contact pagina met form) om te kijken of het lekker werkt. De documentatie is goed te lezen en de opbouw is simpel.

Het komt nu inderdaad voor deze simpele website een beetje log over (heel veel files, caches, e.d.) maar ik wil het toch eens proberen. Het voordeel van een bestaand framework vind ik de afhandeling van 'losse eindjes' in zelfgemaakte php-pagina's. Als ik in symfony per ongeluk errors veroorzaak heb ik out-of-the-box al een redelijke error-afhandeling. Maar goed dat kan maar zo verandere nals mijn code iets complexer wordt

Ben benieuwd hoe ik het ga vinden, ik stoei in ieder geval weer even verder met mijn hello-world en contact pagina/form.

[Amanush]

DJMaze schreef op dinsdag 12 mei 2015 @ 14:36:
[...]

Klopt als een bus!
Ik gebruik geen Laravel noch Symfony noch Smarty noch Zend noch Yii noch whatever.
Ben er achter gekomen dat de meesten gewoon veel te loch en zwaar zijn voor iets simpels als een website.
En vreemd genoeg gebruik ik toch mijn eigen REST framework.

Er is gewoon geen holy grale, gebruik waar je je prettig bij voelt.

Mijn set bestaat vooral uit RFC's, Zope TAL (in PHP) en ANSI/ISO SQL via MySQLi.

[...]

Ik gebruik nu Ruby on Rails. Een MVC-framework op basis van Ruby waar ik heel productief in kan zijn. Ik schrijf op het moment een framework in Javascript (Ga ik met NodeJS draaien). Bedoeling is, is dat ik nog productiever met dat framework ben als in Rails.

DJMaze schreef op dinsdag 12 mei 2015 @ 14:36:
[...]

Daarnaast zijn al mijn bestanden lowercase omdat de php autoloader gewoon zo werkt, en het voorkomt problemen bij Windows ontwikkelaars die iets uploaden naar een UNIX systeem.
Snap niet dat er bijna geen een framework is dat hier rekening mee houdt.

Apple Mac OS X (UNIX- / POSIX-like) gebruikt ook een case insensitive filesystem.

[Barryvdh]

DJMaze schreef op dinsdag 12 mei 2015 @ 14:36:
[...]
Daarnaast zijn al mijn bestanden lowercase omdat de php autoloader gewoon zo werkt, en het voorkomt problemen bij Windows ontwikkelaars die iets uploaden naar een UNIX systeem.
Snap niet dat er bijna geen een framework is dat hier rekening mee houdt.

Amanush schreef op dinsdag 12 mei 2015 @ 17:13:

Apple Mac OS X (UNIX- / POSIX-like) gebruikt ook een case insensitive filesystem.

Daarnaast maakt het ook niet uit of je dan alleen maar kleine letters gebruikt, of begint met hoofdletter, of hetzelfde als de naam van de class. Je moet het sowieso gewoon goed doen

Beter gebruik je gewoon PSR-4, zoals moderne frameworks doen, in plaats van je eigen standaard te bedenken

[Amanush]

Barryvdh schreef op dinsdag 12 mei 2015 @ 17:20:
[...]


[...]


Daarnaast maakt het ook niet uit of je dan alleen maar kleine letters gebruikt, of begint met hoofdletter, of hetzelfde als de naam van de class. Je moet het sowieso gewoon goed doen

Beter gebruik je gewoon PSR-4, zoals moderne frameworks doen, in plaats van je eigen standaard te bedenken

+1 voor het noemen van PSR-4.

[BtM909]

Amanush, het is hier geen facebook of andere +1 platform. Voeg wat toe (ontopic) of reageer niet

[DJMaze]

Barryvdh schreef op dinsdag 12 mei 2015 @ 17:20:
Daarnaast maakt het ook niet uit of je dan alleen maar kleine letters gebruikt, of begint met hoofdletter, of hetzelfde als de naam van de class. Je moet het sowieso gewoon goed doen

Beter gebruik je gewoon PSR-4, zoals moderne frameworks doen, in plaats van je eigen standaard te bedenken

Ehm... PSR-4 is een eigen standaard, bedacht door gewoon wat meer mensen.
En zoals je ziet in de voorbeelden is er een mix van verschillende paden met en zonder lowercasing, en zelfs met dashes ipv (back)slash.
Totaal onsamenhangend dus.

spl_autoload is de standaard van php.
En daarin staat letterlijk

The lowercased name of the class (and namespace) being instantiated.

Hier is dus met de voorbeelden uit PSR-4:

\Acme\Log\Writer\File_Writer = ./acme/log/writer/file_writer.php
\Symfony\Core\Request = ./symfony/core/request.php
\Zend\Acl = ./zend/acl.php

Dat is dus eenduidig altijd het zelfde.
PHP zelf is case-insensitive. Het maakt ook geen reet uit als je een class aanroept als "\zend\acl"
En iemand die per ongeluk op windows \Zend\ACL typt zal het probleem pas merken als zijn code naar UNIX machine verhuist met PSR-4.
Met spl_autoload zou hij minder snel in de problemen komen.

[ Voor 10% gewijzigd door DJMaze op 12-05-2015 23:55 ]

[Cartman!]

Je denkt het beter te weten dan de groten in de php-wereld, je goed recht. Je snijdt denk ik jezelf vooral in de vingers door alle prachtige tools die er zijn te negeren. Sinds Composer hoef ik zelden meer zelf dingen from scratch te verzinnen en autoloader? Gewoon die van composer laden en klaar ben ik. Fouten maken qua naamgeving is ook vrijwel onmogelijk met een goede IDE.

DJMaze schreef op dinsdag 12 mei 2015 @ 23:52:
Hier is dus met de voorbeelden uit PSR-4:

\Acme\Log\Writer\File_Writer = ./acme/log/writer/file_writer.php
\Symfony\Core\Request = ./symfony/core/request.php
\Zend\Acl = ./zend/acl.php

En als jij een package wil gebruiken die PSR-1 of PSR-4 volgt dan ga je eerst alles zitten renamen of ga je voor ieder dingetje opnieuw t wiel uitvinden?

[ Voor 37% gewijzigd door Cartman! op 15-05-2015 12:18 ]

[maarud]

Om nog even terug te komen op Symfony
Ik heb gemerkt dat het maken van statische pagina's, simpele mail-forms en basic CRUD-zaken vrij makkelijk gaat, handmatig maar natuurlijk zeker met de CLI generator.

Maar zodra het wat moeilijker wordt dan merk ik dat het nog best even lastig is om het jezelf aan te leren. De documentatie is niet heel duidelijk over Form Collections en ook zijn er weinig tutorials te vinden over dit onderwerp (of ik zoek niet goed).

Wat ik dus wil is een formulier voor bijvoorbeeld het toevoegen van een taak, en die taak kan toegewezen worden aan meerdere personen (of een taak kan meerdere tags bevatten, etc).

Nu weet ik dat ik het met deze bouwstenen moet doen:
- OneToMany annotations in de Entities
- Form Collections
- En wat basic jQuery om extra veldjes toe te voegen

Maar, het 'kookboek' van Symfony mist de benodigde Doctrine annotations en de twee tutorials die ik gevonden heb zijn ook niet 100% compleet (deze en deze).

Met wat prutsen kom je een heel eind en het lukt uiteindelijk vast ook wel, maar om het wat sneller te laten gaan, ben ik benieuwd of iemand nog goeie websites of webinars voor dit weet?