PHP application framework

[willemj]

Omdat de markt blijkbaar PHP interessanter vindt dan Perl (wat ik nu voornamelijk gebruik) ben ik maar eens PHP gaan leren. Het wiel opnieuw uitvinden is ook niets dus ik wil gelijk een application framework gaan gebruiken. Nu ken ik geen php specifieke fora dus stel ik m'n vragen hier maar om te beginnen.

 

Ik ben tot nu toe drie frameworks tegengekomen die interessant lijken: Zend framework, symfonie en seagull. Ben begonnen met Zend en dat ziet er aardig uit maar ben nog niet tegen de limieten aangelopen. Zijn er naast deze drie nog andere frameworks?

 

Wie heeft ervaring met één of meerdere van deze frameworks en kan mij vertellen hoe stabiel ze zijn (zowel qua API als in gebruik) En hoe is de support van de ontwikkelaars? Kennis van me heeft meerdere uitgebreide bug reports met fix gedaan voor Zend die na een aantal maanden nog niet gefixed zijn, is een minpuntje.

 

Informatie over gebruik binnen de nederlandse markt is erg welkom. Suggesties voor meer toepasselijke fora voor deze vraag ook natuurlijk.

[renep]

een oplossing die je als architect binnen je bedrijf ook aan je management kunt voorleggen als solution die op een aantal punten in je feasibility studie binnen de lange termijn IT oplossing binnen je bedrijf kunnen passen.

 

ehm, en? Ik dacht dat dit een forum was voor ondernemers, niet voor business consultants met wollige newspeak.

 

Volgens mij bedoelt hij: "misschien kun je er op den duur iets mee" :)

[Christine]

een oplossing die je als architect binnen je bedrijf ook aan je management kunt voorleggen als solution die op een aantal punten in je feasibility studie binnen de lange termijn IT oplossing binnen je bedrijf kunnen passen.

 

ehm, en? Ik dacht dat dit een forum was voor ondernemers, niet voor business consultants met wollige newspeak.

 

Volgens mij bedoelt hij: "misschien kun je er op den duur iets mee" :)

 

Ah, daar kan ik iets mee.

 

:-)

 

[Erik Duindam]

Na 2 jaar afwezigheid (druk druk druk) ben ik weer terug op het forum, en ik zie dus bij deze direct een interessante vraag.

 

Goede PHP frameworks zijn er niet zo veel naar mijn mening. Ik gebruik zelf een eigen framework maar heb ook ervaring met het Zend framework. Ik ben zelf sinds kort Zend Certified Engineer in PHP 5, dat zijn er een stuk of 40 in Nederland. Ik heb met een paar anderen gesproken die hetzelfde diploma hebben, en die gaan eigenlijk allemaal voor het Zend framework. Eigenlijk bevat dit framework alles, van database tot PDF tot filehandling tot het filteren van input en escapen van output.

 

Het klopt dat heel veel websites en systemen die gebruik maken van PHP zo lek als een mandje zijn. Nu kun je dus de discussie voeren of dit komt door de taal of door de programmeur. Ik vind echter de situatie niet zo zwartwit. Het is namelijk zo dat de taal in een aantal opzichten erg veel toelaat. Dat zorgt aan de ene kant voor flexibiliteit en aan de andere kant voor een grotere kans op fouten en bugs. Uiteindelijk is dit de zorg van de programmeur. Maar ik wil het graag iets verder nuanceren. PHP is best een apart geval. Bijna iedere PHP programmeur heeft de taal zichzelf aangeleerd met behulp van internet en fora. Je leert het niet zo heel snel bij een opleiding. Daarnaast zijn er erg veel PHP programmeurs en is alleen de nieuwere versie, PHP 5, in een aantal opzichten geschikt voor goed beveiligde systemen. Het komt er dus op neer dat heel veel mensen nog nooit literatuur hebben gelezen over het beveiligen van hun scripts en dat mensen het massaal fout leren op internet. Uiteindelijk kun je dit niet de makers van PHP kwalijk nemen.

 

Bottomline, ik zou voor Zend Framework gaan. Ik zal kijken of ik straks een paar goede PHP programmeurs kan spreken en kan vragen over hun ervaringen met een aantal frameworks.

 

Ben blij om weer terug te zijn hier!

 

Groeten,

 

Erik

[R.I.P. | Peter Bonjernoor]

Goede PHP frameworks zijn er niet zo veel naar mijn mening.

 

Ik heb onlangs voor het eerst naar ModX gekeken, en dat ziet er alles bij elkaar helemaal niet verkeerd uit. Is een beetje een combinatie van framework en CMS - wel eens gezien?

[djluc]

ModX ken ik niet. Wel werken wij erg veel met Typo3. Dat is ook een framework waarop een CMS gebouwd is. Het is echter ook goed mogelijk om een script te maken (bijvoorbeeld een commandline script) op basis van het framework zonder iets met het CMS deel te maken te hebben.

 

Ik denk ook niet dat veel frameworks ontwikkeld zullen worden zonder iets van een CMS systeem daarop. Dat is tegenwoordig toch bijna noodzaak en daarnaast heb je al een groot deel (login e.d.) geregeld in je framework waardoor het extra werk ook wel meevalt.

[Alef Arendsen]

Maar puur een taal afserveren als onveilig doet PHP echt te kort.

 

I almost wanted chime in, maar ik zal m'n mond maar houden ;-)...

[Wouter.]

@Erik Duindam:

 

Is het zend certificaat tegenwoordig wel waard om te halen? het eerste zend certificaat ging niet verder dan basale kennis over syntax en functions.

 

 

ontopic: ik zou kijken naar zend, cakephp e.d.

[Deimos]

Pak in ieder geval een PHP 5 only framework en niet bijv Cake dat ook moet kunnen draaien op PHP 4. Versie 4 is achterhaald en inmiddels EOL. Kortom zover mogelijk vandaan blijven.

[Wouter.]

PHP4 is op zich niet achterhaald.. de EOL is op 31 dec. Dit betekent alleen geen support meer.

 

Ik denk dat er nog veel hosters binnen NL draaien op PHP4 en dat de echte overstap naar 5 of straks 6 nog wel lang gaat duren... Ook al gaan mensen het eisen.

[mark1234]

Veel hosters zijn juist al overgestapt of gaan dat voor het eind van het jaar nog doen. Veel hosters stoppen in 2008 juist volledig met de ondersteuning van PHP4 (vaak draaien ze eerst tijdelijk beide PHP versies naast elkaar).

[Gelderblom Internet Solutions]

PHP4 is op zich niet achterhaald.. de EOL is op 31 dec. Dit betekent alleen geen support meer.

 

Ik denk dat er nog veel hosters binnen NL draaien op PHP4 en dat de echte overstap naar 5 of straks 6 nog wel lang gaat duren... Ook al gaan mensen het eisen.

 

Geen support is denk ik geen klein probleem en ik heb het idee dat je (wellicht onbedoeld) het wel als iets kleins voordoet. Geen support betekent dat elke beveilingsprobleem in PHP4 die nog gevonden wordt, niet meer gerepareerd wordt. Dat kan je niet verkopen aan klanten. Zodra professionele bedrijven PHP5 draaien gaan webhosters vanzelf mee om aan de vraag te voldoen. Volgens mij is dat al ruimschoots aan de gang. Ik ken maar weinig webhosters die geen PHP5 ondersteuning hebben en de meeste vacatures voor PHP webdevelopers gaan over PHP5.

[msteer]

Ik vond toevallig dit onderzoekje over php frameworks. Geen meningen, maar feiten over de codebase, activity & participants.

 

@willemj: ben je verder gegaan met php? en met welk framework?

[willemj]

Ik vond toevallig dit onderzoekje over php frameworks. Geen meningen, maar feiten over de codebase, activity & participants.

 

@willemj: ben je verder gegaan met php? en met welk framework?

 

Dat zijn altijd leuke en handige statistieken. Ben wel eens aan de slag gegaan met een OS projectje dat al een jaar of twee compleet dood bleek te zijn.

 

Ik ben inderdaad verder gegaan met PHP met het Zend framework. Zit een commerciele club achter, goede license (BSD) en had zo'n beetje alles wat ik nodig had.

[Christine]

Ik vond toevallig dit onderzoekje over php frameworks. Geen meningen, maar feiten over de codebase, activity & participants.

 

@willemj: ben je verder gegaan met php? en met welk framework?

 

Dat zijn altijd leuke en handige statistieken. Ben wel eens aan de slag gegaan met een OS projectje dat al een jaar of twee compleet dood bleek te zijn.

 

Ik ben inderdaad verder gegaan met PHP met het Zend framework. Zit een commerciele club achter, goede license (BSD) en had zo'n beetje alles wat ik nodig had.

 

Maar laat wel checken of je applicatie wel veilig is. Het is zo makkelijk om met php websites met grote gaten te maken. Het probleem van een framework is dat je de gaten niet altijd zelf in de hand hebt. Joomla is b.v. niet waterdicht.

 

 

 

[Michiel van Vlaardingen]

Dat is ook mijn/onze reden om uiteindelijk gewoon zelf langzaam een library/framework op te bouwen. Absoluut niet veiliger, want je maakt zelf ook fouten, maar als je eenmaal iets vind heb je wel zelf de mogelijkheid om het direct op te lossen.

 

Wat ik iig aan Zend mooi vind is dat je zelf kan beslissen hoe veel je gebruikt. Wij gebruiken momenteel bijvoorbeeld zonder problemen alleen de search uit het Framework. Ik weet niet hoezeer dit ook geld voor de andere Frameworks, die ken ik daarvoor niet genoeg.

[willemj]

Maar laat wel checken of je applicatie wel veilig is. Het is zo makkelijk om met php websites met grote gaten te maken. Het probleem van een framework is dat je de gaten niet altijd zelf in de hand hebt.

 

Dat een ander een lek voor je kan introduceren klopt helemaal. Maar daar hoef je geen grote brokken code voor te gebruiken. De XMLRPC library bevatte een tijd terug een lek waardoor (onder andere) wordpress blogs misbruikt konden worden. Blijft uitkijken, afwegen wat je op het grote boze internet zet en dagelijks de security bulletins volgen.

[willemj]

Absoluut niet veiliger, want je maakt zelf ook fouten, maar als je eenmaal iets vind heb je wel zelf de mogelijkheid om het direct op te lossen.

 

Ik gebruik de Yahoo user interface library en ben daar al de nodige bugs in tegen gekomen (met 150k regels niet zo vreemd) Deze heb ik zonder al te veel probleem direct kunnen fixen. Kost alleen wat tijd om thuis te raken in de code maar dat is meer dan de moeite waard.

[Christine]

Dat is ook mijn/onze reden om uiteindelijk gewoon zelf langzaam een library/framework op te bouwen. Absoluut niet veiliger, want je maakt zelf ook fouten, maar als je eenmaal iets vind heb je wel zelf de mogelijkheid om het direct op te lossen.

 

Maar als je zelf maakt ben je maar alleen. Een open source library wordt aan meer gebruik blootgesteld en zal dus iha veiliger zijn. Maar als zelfs de meest gerenommeerde open source email frameworks regelmatig bugs hebben, wat moet je dan zelf? In php maak je gewoon makkelijker beveiligingsfouten dan wanneer je b.v. java en Tapestry gebruikt.

[Michiel van Vlaardingen]

Ik denk dat dat inderdaad in het algemeen geldt, maar alleen voor breed gedragen open source software zoals Apache, Firefox, etc. Ik wil dan ook absoluut niet beweren dat zelf schrijven veiliger is, alleen dat het oplossen van gevonden fouten gemakkelijker kan zijn.

 

Er zijn echter ook veel prutsers in deze wereld. De source van menig PHP open source project is echt om te huilen. (van closed source projecten net zo erg overigens)

 

Daarnaast bieden frameworks vaak meer functionaliteit dan je er van gebruikt, daar kunnen allemaal fouten in zitten.

 

Een vervelend punt bij frameworks is dat je er van afhankelijk bent en dat voor het verkrijgen van een fix voor een lek, vaak geupgrade moet worden naar een volgende versie. Iets wat zelden pijnloos is.

 

Nu wil ik helemaal niet het gebruik van open source frameworks ontmoedigen. Maar, het is in ieder geval zeker niet zwart-wit en het waard om per project een afweging te maken.

 

Overigens is mijn belangrijkste motiviatie om zelf te schrijven dat er gewoon niet echt een PHP Framework is wat mij aanspreekt. Misschien wel een gevalletje 'Not-Invented-here', waarover http://www.joelonsoftware.com/articles/fog0000000007.html wel een erg leuk artikel is.

 

 

[joeph]

Dat is ook mijn/onze reden om uiteindelijk gewoon zelf langzaam een library/framework op te bouwen. Absoluut niet veiliger, want je maakt zelf ook fouten, maar als je eenmaal iets vind heb je wel zelf de mogelijkheid om het direct op te lossen.

 

Maar als je zelf maakt ben je maar alleen. Een open source library wordt aan meer gebruik blootgesteld en zal dus iha veiliger zijn. Maar als zelfs de meest gerenommeerde open source email frameworks regelmatig bugs hebben, wat moet je dan zelf? In php maak je gewoon makkelijker beveiligingsfouten dan wanneer je b.v. java en Tapestry gebruikt.

 

Beveiligingsfouten hebben niets maar dan ook niets met de taal waarin geschreven wordt te maken! De vergelijk met java tapestry is hier niet van toepassing omdat tapestry een framework is en geen taal. Dat zou hetzelfde zijn als php zend framework vergelijken met Java.

Php is eenvoudiger en dus laagdrempeliger dan java waardoor er ook niet-programmeurs mee aan de slag gaan. Dan zijn de rapen inderdaad gauw gaar.

Maar in java of welke programmeertaal dan ook, kun je dezelfde security fouten maken zoals sql injections, cross site scripting attacks om er een paar te noemen.

 

[joeph]

@Christine: een programmeertaal is niet onveilig, wat mensen ermee doen is wat het onveilig maakt. PHP is perfect veilig te maken (en ook zeer onveilig, wij stuiten regelmatig op lekken of foutieve code). Maar puur een taal afserveren als onveilig doet PHP echt te kort.

 

Deze korte door de bocht reacties blijven maar terugkomen bij Cristine. Het is iets persoonlijks tegen php!

[willemj]

Beveiligingsfouten hebben niets maar dan ook niets met de taal waarin geschreven wordt te maken!

 

Eindverantwoordelijke is de programmeur natuurlijk. Maar ja, dan kom ik als goede programmeur een taal tegen waarin een array spontaan verandert in een hash (associative array voor de liefhebber) of een soort vage hybride tussen beide afhankelijk van wat ik als index gebruik en ik welke volgorde. Strak en (dus) veilig programmeren doe je met strakke talen.

 

Maar goed dit is offtopic voor zowel dit draadje als HL.

 

 

[joeph]

Ik zou voor Zend gaan.

Het is nog redelijk in ontwikkeling in vergelijking met Cake of Symphony maar ze halen zeer snel in. Een groot voordeel is dat er een stel sterke partijen achter zitten (IBM, Oracle) en dat levert geld op en voorspoedigt de ontwikkelingen.

 

Oracle levert standaard php als engine mee in zijn applicatieserver en zelfs Microsoft draait het op zijn IIS in fast cgi mode.

[mordamus]

Ik zou voor Zend gaan.

Het is nog redelijk in ontwikkeling in vergelijking met Cake of Symphony maar ze halen zeer snel in. Een groot voordeel is dat er een stel sterke partijen achter zitten (IBM, Oracle) en dat levert geld op en voorspoedigt de ontwikkelingen.

 

Oracle levert standaard php als engine mee in zijn applicatieserver en zelfs Microsoft draait het op zijn IIS in fast cgi mode.

 

Ben hier mee eens, ook de nauwe samenwerking met PHP zelf heeft voordelen. Wij leveren dit pakket al standaard bij hosting pakketten.