[PHP] Nieuw project, hoe aan te pakken?

[Mei]

Korte samenvatting van mijn PHP-ervaring:
- Jaar of 5 geleden begonnen, nogal baggere kleine cmsjes gemaakt. Hardcoded strings en markup, geen beveiliging tegen MySQL injections enz.
- Ervaring met scripting. Ik weet hoe alles in elkaar steekt enzo, dus wat dat betreft niet echt een newbie.
- Laatste tijd vooral bezig met werken met [url=http:/drupal.org/]Drupal[/url]. Dingen aanpassen, modules schrijven enz. Weinig grote dingen dus.

Ik wil nu een wat groter project gaan maken. Is geen compleet framework, maar wat er wel in moet zitten:
- Userbase (puur voor administratieve taken. Men logt in en heeft toegang tot inhoud. Verder een profielen ofzo)
- Rewriteurls (het script moet alles afhandelen)
- Admin sectie om alles in te stellen.

Opzich verwacht ik wel dat ik dit kan scripten, waar ik even mee zit is de opbouw van dit alles. Ik heb zoals je hebt gezien geen (goede) ervaring met grotere projecten, dus ik heb niet echt een idee hoe ik dit aan moet pakken, zodat ik het wel een beetje flexibel houd. Ik ben van Drupal gewend gemakkelijk nieuwe pagina's met hele formulieren aan te maken. Dit gemak komt door het framework. Ik heb er al aan zitten denken Drupal te gebruiken en voor deze speciale functionaliteit die ik wil een eigen module te schrijven, maar 1) Drupal zelf bevat nog wat dingen die ik niet nodig heb, zoals content aanmaken en alles en 2) Ik zou het toch eigenlijk wel graag zelf willen proberen.

Heb al naar wat info gezocht, maar het is een beetje lastig hier wat over te vinden, want op welke keywords moet je zoeken? Daarom had ik gehoopt dat de meer ervaren devvers hier me wat konden uitleggen of een paar artikelen konden aanrijken

[Megamind]

Tja zat artikelen hierover op de bekende sites:
www.phpfreakz.nl zal wel wat staan. Je kan het gewoon stap voor stap in elkaar draaien en proberen het allemaal aan elkaar te knopen later

[Mei]

Nou, dat is het hem juist. Ik wil het niet zomaar een elkaar proberen te knopen. Ik zoek een goede manier om er structuur in te krijgen. Misschien zelfs een soort klein frameworkje van te maken waarmee ik makkelijk bijvoorbeeld pagina's en formulieren in elkaar kan draaien. De losse dingen maken is het probleem niet, de structuur wel.

[RomeoJ]

Begin iniedergeval met een goede structuur, maak dus gebruik van classes.

Dus, Object Georienteerd Programmeren zou goed zijn om eens door te nemen, op google zou je daar wel een heleboel over kunnen vinden, klassen, overerving, enz.. zit daar allemaal in.

[sky-]

Schrijf eerst een plan hoe je precies te werk wil gaan.
Werk alles in stappen uit; zodat je niet voor rare dingen komt te staan als je eenmaal bezig bent.

Ook van te voren netjes je database plan bedenken, zodat je je applicatie mooi kan schrijven zonder dat je steeds je database layout moet aanpassen.

Succes!

[CoolGamer]

Het perse gebruik van classen is niet nodig om een structureel goede applicatie te maken. Maar het zou zeker kunnen helpen om onderdelen van het programma te scheiden in verschillende bestaden, zodat je het makkelijk kan vinden als je er wat aan wilt veranderen.

De belangrijkste eerste stap is altijd, wat moet de applicatie kunnen. Dit zo dat je vanaf het begin er met je ontwerp rekening mee kunt houden. Soms achteraf toevoegen is heel lastig. Bedenk ook hoe de layout van de site eruit gaat zien en probeer css te gebruiken, zodat je achteraf de layout snel kunt aanpassen of bijwerken.

[sky-]

Volgens mij heb jij er nog niet zoveel ervaring mee TheCoolGamer, een layout is iets waar je bij een applicatie op 't begin niet aan denkt. Dat kan later allemaal wel.

Alles in aparte bestanden hoeft echt niet, maar het is wel bijvoorbeeld (zoals jezelf zegt) om elke classe op een andere pagina te houden, zodat je het -idd- makkelijker kan aanpassen.

[Onbekend]

Om te beginnen zet je een aantal punten op papier:
Functionaliteit, database opbouw, veiligheden die je wilt gebruiken, afscherming bepaalde gedeelten enz.

Vervolgens maak je een eenvoudige maar werkende kale opzet voor een bepaald gedeelte. Dus bijvoorbeeld het inloggen van een gebruiker. Als dit goed werkt kan je vervolgens je veiligheden inbouwen zoals het escapen van tekens en query-misbruik voorkomen.
Als die functionaliteit af is is hij af en zou je deze in theorie nooit meer aan hoeven te passen.

In dit eerste gedeelte kom je waarschijnlijk dingen tegen die je liever anders had gedaan. Maar dat kan je nu alsnog aanpassen en deze ervaring kan je weer gebruiken voor de andere gedeeltes van de site.

Houd wel alles gescheiden zoals
html-code
css
php -> invoer van gegevens.
php -> verwerking van gegevens.
php -> database communicatie.

[Coju]

Kijk eens even naar frameworks als Cakephp, Symphony en CodeIgniter. Er zijn nog tig andere, Zend Framework bijvoorbeeld, maar ze kunnen wel goed helpen om een applicatie te structureren.

[CoolGamer]

k8skaaay schreef op woensdag 17 oktober 2007 @ 22:36:
Volgens mij heb jij er nog niet zoveel ervaring mee TheCoolGamer, een layout is iets waar je bij een applicatie op 't begin niet aan denkt. Dat kan later allemaal wel.

De layout is zeker iets waar je aan het begin naar zou gaan kunnen kijken. Zodra je alle eisen op een rijtje hebt, kan je gaan kijken hoe je het duidelijk in beeld wilt gaan brengen. (Is eigenlijk ook 1 van de eisen, de layout) Dan hoef je layout niet te letterlijk nemen, zoals achtergrond geel en tekst zwart, maar meer in de vorm van hoe zorg ik er uiteindelijk voor dat alle pagina's dezelfde stijl hebben, wat komt er op de pagina's te staan, hoe ziet de navigatiestructuur er uit. Als je daar op het einde pas naar kijkt is het vrij lastig om een consequent uitziende website te krijgen.

offtopic:
Ik heb inderdaad nog niet zoveel websites gemaakt, maar heb er wel training in gehad. Je moet eerst een siteplan opstellen. Daarin geef je ook een functioneel ontwerp op. Zodra je dat hebt, heb je de layout al in grote lijnen.

[truegrit]

Het gaat ook totaal niet over de layout van de website waar de TS vragen over heeft. Het gaat hem om de opbouw van de code. Een layout kan je later wel maken met een leuke template engine of iets dergelijks, in principe is het gewoon een representatie van je content. Het lijkt me dus niet verstandig om in dit topic (wat volgens mij meer in S&A hoort) over css/html enzo te gaan praten.

En het is trouwens netjes om dit toch van elkaar gescheiden te houden, dus met dat MVC pattern ofzoiets!

[FragFrog]

truegrit schreef op donderdag 18 oktober 2007 @ 00:15:
En het is trouwens netjes om dit toch van elkaar gescheiden te houden, dus met dat MVC pattern ofzoiets!

Exactly.

Als jij de layout van je site niet kan veranderen zonder aan je PHP te zitten ben je al principieel fout bezig. Er zijn verschillende manieren om dit voor elkaar te krijgen zoals XSLT's of het gebruik van template engines als smarty, veel goede frameworks hebben daarnaast vaak ook al hun eigen manieren om een MVC implementatie te bewerkstelligen. Het kan geen kwaad je hierin in te lezen

Een goed framework bouw je langzaam op vanuit een stabiele basis. Wat in mijn ervaring goed werkt is zorgen dat je het laden van objecten en het bepalen van welke actie genomen moet worden centraliseert, met andere woorden begin met een degelijke pagehandler die alle requests af kan handelen. Als je een global context object gebruikt kun je vervolgens op een simpele manier vanuit verschillende objecten bepaalde standaardfunctionaliteit aanspreken zoals een database handler of content loader. Als vervolgens je objecten klaar zijn met de gegevens laden etc knal je 't weer terug naar je pagehandler die vervolgens begint met gegevens in je template zetten en deze weergeven.

As for login etc, bedenk vantevoren of je genoeg hebt aan userlevels of dat je een volwaardig acl moet schrijven / gebruiken. Dit bepaalt hoe (en waar) je pagehandler met toegangsrestricties omgaat en zorgt ervoor dat je niet een wirwar aan controles door je hele code heen krijgt

[SchizoDuckie]

FragFrog schreef op donderdag 18 oktober 2007 @ 01:07:
[...]

Exactly.

Als jij de layout van je site niet kan veranderen zonder aan je PHP te zitten ben je al principieel fout bezig. Er zijn verschillende manieren om dit voor elkaar te krijgen zoals XSLT's of het gebruik van template engines als smarty

Hier ben ik het dus expliciet *NIET* mee eens... PHP IS de template language. elke extra laag die je daar bovenop legt is naar mijn mening overhead, en vooral dingen als smarty zijn zo verschrikkelijk bloated dat je echt een giga performance impact krijgt en je maakt een template engine bovenop een templating language

Een template file zou niets meer moeten zijn dan een standaard php file waarin je met wat for loopjes door een aantal wat beschikbare template variabelen heen kan lopen. Het is echt onzin om dat bij PHP vandaan te abstraheren imo.
Iemand die het wel goed doorheeft en er een mooi verhaaltje omheen gebouwd heeft heeft dat hier neergedumpt.

[ Voor 8% gewijzigd door SchizoDuckie op 18-10-2007 09:37 ]

[FragFrog]

Weet je uberhaupt wel waar je het over hebt? Ten eerste 'compiled' smarty je templates zodat wat uiteindelijk gebruikt wordt precies hetzelfde is als wat jij gebruikt, namelijk een PHP file met wat for loops etc. Dat compilen gebeurt 1 keer nadat je template aangepast is en dientengevolge heeft smarty zo goed als geen performancedrain whatsoever.

Daarnaast kun je juist met een goede template engine simpel delen van je site cachen zodat ze nog sneller worden. Dankzij Smarty kan mijn blog bijvoorbeeld meestal met 1 query geladen worden in plaats van de 5 die er nodig zouden zijn als er niet gecached zou worden. Netto levert me dat 70% minder parsetime op! Bedenk dat verreweg het grootste gedeelte van je parsetime gaat zitten in SQL queries, als je juist daar -simpel- op kan besparen levert dat veel meer op dan wat het je kost aan die paar extra checks die smarty in z'n gecompilde versies gooit.

Ja, als je een template engine puur gebruikt om HTML van PHP te scheiden ben je zo goed als nutteloos bezig, maar dat is ook niet het doel - het doel is om je business logic en presentation logic te scheiden. Er zijn ook prima manieren om dat voor elkaar te krijgen nagenoeg zonder overhead trouwens (denk aan XSLT's) maar daar lever je weer functionaliteit en gemak voor in.

Anyway, deze discussie is hier al een duizend keer gevoerd zonder resultaat - beide kampen hebben hun fanatieke voor- en tegenstanders, daar zal wel niet zo snel wat aan veranderen Wat je er trouwens ook van vind, je zal nog steeds moeten toegeven dat het gebruik van templates de manier is om een goede scheiding van business en presentation te vereisen, en als je in je templates niet direct PHP gebruikt is de verleiding om toch dingen te gaan mengen al een stuk minder

[Mei]

Ik was al van plannen classes te gebruiken. Alhoewel ik daar nog erg weinig mee gewerkt heb en misschien nog niet altijd het nut van in zie, wil ik het toch gebruiken voor een beetje structuur en om er gewoon wat mee te werken, leren hoe het in de praktijk gaat.

Ik wil eigenlijk wel graag met een template systeem werken, sowieso om client-sided code van de server-sided code te scheiden, maar inderdaad ook om content flexibel in te kunnen voegen. Wat ik altijd erg lastig vind (heb er wel eens over nagedacht) is zorgen dat je de markup tussen de dynamisch gegenereerde content kan aanpassen. Stel dat je een menu uit de DB haalt en daar een UL van wil maken. Hoe zorg je ervoor dat dat flexibel gebeurt? Ik heb nu dus ervaring met de PHPTemplate engine van Drupal, misschien maar eens kijken of ik die voor mijn projectje kan gebruiken, net als het form framework (scheelt voor mij ook weer, heb ik wel veel functionaliteit en flexibiliteit, maar hoef ik voor dit eerste echte project van mij niet gelijk gigantisch veel te doen)

[Verwijderd]

SchizoDuckie schreef op donderdag 18 oktober 2007 @ 09:13:
Een template file zou niets meer moeten zijn dan een standaard php file waarin je met wat for loopjes door een aantal wat beschikbare template variabelen heen kan lopen. Het is echt onzin om dat bij PHP vandaan te abstraheren imo.

Deze discussie ga ik niet opnieuw voeren, maar het lijkt mij nogal dogmatisch om te stellen dat, indien je met PHP werkt, je geen andere techniek mag gebruiken om je view te definiëren. Iedereen heeft zo zijn voorkeur, en de ene website of webapplicatie is de ander niet.

[zwippie]

Ik zou zeker eens kijken naar het al eerder genoemde CodeIgniter. Een lekker framework waar veel zaken al voor je geregeld zijn zoals url rewriting, db layer met active record, mvc, etc. Erg makkelijk uit te breiden met user accounting en een leuke admin sectie zoals je wilt doen. Het is geen CMS oid dus alle inhoud van de site zul je zelf nog moeten vormgeven.

Persoonlijk vind ik het erg prettig werken en een enorme timesaver. Het biedt genoeg aanknopingspunten om je 'eigen systeem' mee te maken maar is niet al té bloated.

[Onbekend]

Verwijderd schreef op donderdag 18 oktober 2007 @ 10:42:
[...]

Deze discussie ga ik niet opnieuw voeren, maar het lijkt mij nogal dogmatisch om te stellen dat, indien je met PHP werkt, je geen andere techniek mag gebruiken om je view te definiëren. Iedereen heeft zo zijn voorkeur, en de ene website of webapplicatie is de ander niet.

Ik denk dat hij bedoeld dat je je pagina met php mag genereren. (Bijvoorbeeld alle berichten van een gastenboek onder elkaar zetten.)
Dat mag wel, maar ik raad dan wel aan om de functionaliteit en de user interface duidelijk gescheiden maken.

[Mei]

Ff niet zo lopen bakkeleien over het gebruik van template engines Ik vind dat ze wel degelijk nut hebben, maar dan is het wel (voor de performance) zo handig als er geen alternatieve syntaxen zijn en dergelijke.

@zwippie: Het nadeel aan al die frameworks en CMS'en is dat het er zoveel zijn en iedereen zijn of haar keuze het beste vindt. Ik maak nu al goed een jaar gebruik van Drupal en ik vind het heerlijk werken. Er zitten zeker flaws in, maar het is een mooie framework/CMS combo voor websites. Voor zoiets als wat ik nu wil maken is het echter iets te bloated, aangezien er standaard verplichte modules bij zitten om content aan te maken, te uitgebreide userbase (profielen, rechten en alles) enzo. Het makkelijkste voor mij is wel om het hiermee te doen, aangezien ik het systeem ken en wat ik wil er redelijk snel mee voor elkaar kan krijgen, verwacht ik. Nadeel is dus dat het best bloated is. Het is ook de bedoeling dat er niet zoveel mappen en bestanden in de root moeten staan, althans, dat zou het mooiste zijn. Noodzakelijk is het niet, maar toch.

Het gaat er namelijk om dat je bij het systeem gebruikers aan kan maken en die toegang tot bepaalde (fysieke) content op de server kan geven. Alle requests worden naar het systeem geredirect, zodat die de access control kan uitvoeren. Wat ik me nu bedenk is dat ik nog niet goed weet hoe ik (als de gebruiker toegang zou hebben) het opgevraagde pad alsnog ga uitvoeren.