[PHP] Framework

[kamerplant]

In mijn huidige PHP projecten heb ik de indruk te vaak bezig te zijn met het wiel opnieuw uit te vinden, daarbij ben ik ontevreden over de netheid van mijn code. In eerste instantie was ik van plan een simpel eigen framework te maken waardoor ik code met minder moeite zou kunnen hergebruiken en waardoor een betere scheiding tussen php en html mogelijk zou worden. Na overleg met een andere GoT dude die met hetzelfde probleem zit zijn we gaan kijken naar de mogelijkheid om een bestaand framework te gaan gebruiken. De volgende namen kwamen naar boven:

Prado (http://www.xisc.com / http://www.pradosoft.com)
CakePHP (http://cakephp.org)
Seagull (http://seagull.phpkitchen.com)
Stratos (http://www.stratosframework.com)

Zelf ben ik gaan spelen met Prado. Ik ben er tot nu toe vrij enthousiast over, het past het MVC principe toe waardoor de code netjes blijft en ik ben ook erg blij met de Ajax support. Zonder advanced JavaScript kennis zijn Ajax pagina's zonder problemen te genereren. Voordat ik hier mee verder ga zou ik graag ervaringen van andere PHP dudes willen horen wat betreft de genoemde frameworks en eventueel andere nog niet genoemde. Ik vraag je je ervaringen te posten, waarbij ik specifiek geïnteresseerd ben in de beantwoording van de volgende vragen:

• Kost het veel moeite/tijd om het goed onder de knie te krijgen?
• Mis je op ten duur bepaalde flexibiliteit, omdat bijvoorbeeld bepaalde code voor je wordt gegenereerd?
• Hoe zit het wat betreft de performance, treed er veel performance verlies op?
• Is er voldoende shared hosting hosting beschikbaar voor het betreffende framework (zo vereist Prado een bepaald aantal PHP extensies)?
• Het zit het met de documentatie en de achterliggende communities? Is het voorgekomen dat je een groot probleem had, hoe is dat opgelost?
• Zijn er bepaalde knelpunten waar je tegenop liep?

Een tijd geleden werd ik gewezen op Ruby on Rails. Ik werd hierover behoorlijk enthousiast maar besefte dat voor mij het grootste nadeel zou zijn de tijd die het kost om het mij aan te leren. Als ik toch bezig ben een overstap te maken naar een andere style, is Ruby on Rails dan toch alsnog erg interessant om te overwegen, of kan ik het prima buiten beschouwing laten?

offtopic:
Wat betreft mijn eigen skills. Ik heb sinds 2003 ervaring met PHP (en daarbij behorende MySQL, html, css, etc.), ik heb enkele website's en webbased applicaties gebouwd. Het PHPen is niet mijn main-job, in eerste instantie deed ik het voor de lol, nu als bijverdiensten. In het dagelijkse leven doe ik de opleiding Bedrijfskundige Informatica, ik beschouw mijzelf hierdoor niet als "pro" en besteed aan het programmeren dan ook maar een beperkte tijd.

[webschaapje]

*bookmarked

Ik heb eenzelfde achtergrond jezelf. Ik ben dit momenteel zelf ook aan het uitzoeken. Ruby on Rails ziet er leuk uit, maar heb het nog niet geprobeerd. Ik zou ook niet 1-2-3 weten of RoR apps door mijn hoster worden ondersteunt.

Ik heb echter nog wel een toevoeging aan je lijstje, die misschien we interessant is.
Code Igniter - http://codeigniter.com/

[RAJH]

Sinds een aantal dagen is het Zend Framework ook stable. Ik heb er nog niet mee gewerkt dus ik kan zo geen mening erover geven.

[MBV]

Je zou ook eens kunnen kijken wat andere projecten gebruiken. MVC wordt ook toegepast in Joomla 1.5, gebruikt die een van die frameworks?

[Anoniem: 9260]

Kijk ook toch eens naar Symfony Project. Dat is zowat RoR in php


www.symfony-project.com

[aex351]

Ik heb mijn eigen Framework geschreven. Een framework vereist over het algemeen geen extra php extensies. Probleem is dat voor een PHP'er dat nog nooit met frameworks heeft gewerkt het totaal plaatje moeilijk te begrijpen is. De Zend Framework is bijvoorbeeld van een OO gedachte geschreven, maar iemand die puur alleen PHP kan en dus geen echte andere programmeertaal, zal de essentie van OO nooit helemaal kunnen door gronden.

[ibmos2warp]

MBV schreef op donderdag 05 juli 2007 @ 19:17:
Je zou ook eens kunnen kijken wat andere projecten gebruiken. MVC wordt ook toegepast in Joomla 1.5, gebruikt die een van die frameworks?

Joomla is geen framework . En Joomla wordt ook (dacht ik) niet op een framework gebouwd.

[kokx]

Gezien hier toch over frameworks wordt gesproken, zal ik maar meteen een eigen projectje gaan promoten.

Dit is geen nieuw framework, maar een uitbreiding van een bestaand framework. Het Zend Framework natuurlijk. Ik heb er nog niet enorm veel bijgeschreven, maar vanavond begin ik al aan wat veel leukers, een OO interface naar de GD library (voor zover dat mogelijk is met php). Alleen dan met een aantal extra features zoals layers e.d.

Project url:
http://zendext.maaksite.nl

Als iemand hier mee bezig gaat, raad ik hem wel aan alles via Subversion binnen te halen, gezien er toch nog niets echt Stable is.

[ Voor 3% gewijzigd door kokx op 05-07-2007 20:03 ]

[MBV]

MBV schreef op donderdag 05 juli 2007 @ 19:17:
Je zou ook eens kunnen kijken wat andere projecten gebruiken. MVC wordt ook toegepast in Joomla 1.5, gebruikt die een van die frameworks?

ibmos2warp schreef op donderdag 05 juli 2007 @ 19:33:
[...]

Joomla is geen framework . En Joomla wordt ook (dacht ik) niet op een framework gebouwd.

Goh, echt

[ibmos2warp]

MBV schreef op donderdag 05 juli 2007 @ 20:08:
Goh, echt

Wat bedoel je nou? Dat ie joomla als voorbeeld kan gebruiken ofzo?

[Optix]

Hij bedoeld hoe/of andere projecten (dus niet frameworks ) een framework toepassen.

[kamerplant]

Joomla gebruikt zo te zien een eigen ontwikkelde omgeving. Ik las het bericht van MBV eerst ook verkeerd en dacht ook "aah wtf :P". Maarja, beter le-zen de volgende keer

@Kokx. Blijkbaar heb je dus wel ervaring met het onaangepaste Zend Framework. Kun je daar iets over vertellen?

[kokx]

@Datafeest: Zend is nogal een handig framework als je graag gebruiktmaakt van abstractie, echt bijna alles is geabstraheerd. Als je bijvoorbeeld met Zend_Db bezig bent, kom je 3 heel handige dingen daarvoor tegen:
• Zend_Db_Select, voor het creëren van select query's (compatibel met meerdere RDBMS'en).
• Functies voor insert, update en delete. Ook compatibel met meerdere RDBMS'en.
• Zend_Db_Table, eigenlijk gewoon het Model gedeelte van MVC, alleen dan een Zeer goede implementatie.

Het is ook vooral een framework voor de echte applicatie developers. Er wordt je geen echte structuur opgedwongen (zoals bij Symfony bijvoorbeel wel het geval is). Je kunt Zend eigenlijk op een aantal manieren gebruiken. Je kunt bijvoorbeeld slechts delen van Zend gebruiken, zoals het zoek gedeelte (Zend_Search_Lucene) en het mail gedeelte (Zend_Mail) bijvoorbeeld. Maar je zou ook het laad gedeelte kunnen gebruiken, hierbij worden dan automatisch controllers geladen en Views geïnitialiseerd (Zend_Controller).

Om nog even op mijn uitbreiding in te gaan, het Zend Framework zelf wordt onaangeroerd gelaten. Ik maak slechts uitbreidingen, die beginnen met ZendExt i.p.v. Zend.

[Optix]

kokx schreef op donderdag 05 juli 2007 @ 21:21:
• Zend_Db_Select, voor het creëren van select query's (compatibel met meerdere RDBMS'en).
• Functies voor insert, update en delete. Ook compatibel met meerdere RDBMS'en.
• Zend_Db_Table, eigenlijk gewoon het Model gedeelte van MVC, alleen dan een Zeer goede implementatie.

Vind ik wel een beetje minimaal wat ik van een beetje DB class verwacht hoor

[kokx]

Optix schreef op donderdag 05 juli 2007 @ 22:19:
[...]


Vind ik wel een beetje minimaal wat ik van een beetje DB class verwacht hoor

Het zal wss nog steeds je verwachtingen overtreffen, ze gebruiken het factory pattern voor het instantiëren. Eigenlijk hebben ze voor elke vorm van DB connectie een eigen class ( bijvoorbeeld Zend_Db_Adapter_Mysqli, maar ook Zend_Db_Adapter_Pdo_Mysql etc.).

[ibmos2warp]

Optix schreef op donderdag 05 juli 2007 @ 20:33:
Hij bedoeld hoe/of andere projecten (dus niet frameworks ) een framework toepassen.

Jah, nu lees ik het ook....

Struikel al over een zin als er een paar woordjes missen (of iig, naar mijn gevoel)

[Pete]

webschaapje schreef op donderdag 05 juli 2007 @ 18:56:
...
Ik heb echter nog wel een toevoeging aan je lijstje, die misschien we interessant is.
Code Igniter - http://codeigniter.com/

Zeker interessant! Ik ben fervent gebruiker van de codeigniter code.

Grote voordelen:

• Goed MVC-model
• Geweldige Active Record Library. Inclusief handige/goedwerkende escaping ed
• Fijne Form-validator. Hoewel je nog steeds lappen code krijgt voor het valideren van forms is het nu wel duidelijk en gestructureerd
• Low-requirements: PHP4+5 geen modules verplicht, behalve als je iets specifieks nodig hebt. Image-library kan overweg met GD, GD2, ImageMagick (convert), NetPBM
• Fijne en handige profilerclass

Nadelen:

• Heel soms net iets te beperkt. Ik ben dit echter nog weinig tegengekomen.

Om je overige vragen aan te stippen: Korte leercurve (zie de video-tutorial van 20 minuten), goede (echt goeie) documentatie en wordt eigenlijk overal ondersteund op hosting. Knelpunten kan ik niet eens concreet noemen.

[Optix]

kokx schreef op donderdag 05 juli 2007 @ 22:25:
[...]

Het zal wss nog steeds je verwachtingen overtreffen, ze gebruiken het factory pattern voor het instantiëren. Eigenlijk hebben ze voor elke vorm van DB connectie een eigen class ( bijvoorbeeld Zend_Db_Adapter_Mysqli, maar ook Zend_Db_Adapter_Pdo_Mysql etc.).

Smells like Pear

phsmit schreef op donderdag 05 juli 2007 @ 22:38:
[...]
Knelpunten kan ik niet eens concreet noemen.

Ik wel
Heb zelf ook even op CI gewerkt en het grootste nadeel vind ik dat het een grote rommel word als je echt een grote applicatie er op bouwt, een "huis-tuin-en-keuken applicatie" valt nog wel mee.

[ Voor 32% gewijzigd door Optix op 05-07-2007 22:45 ]

[Anoniem: 65297]

Ik gebruik Zend Framework sinds versie 0.2, in het begin was het vooral vervelend dat de api nog vaak veranderde, maar dat is nu eenmaal normaal als het nog niet aan een stable versie zit. Ondertussen is 1.0 uit en zal de api stabiel blijven (was al merkbaar met de laatste releases).

Het grote voordeel van het Zend Framework vind ik de grote vrijheid die je hebt. In tegenstelling tot veel andere Frameworks legt Zend Framework bitter weinig (ik weet er eigenlijk geen) verplichtingen op wat structuur van je applicatie betreft, het heeft wel een soort "best practice" model, maar je doet daarmee wat je wil. Je kunt alles doen op de manier die je zelf wenst, je gebruikt wat je wil uit het framework.
Het is volledig in PHP5 geschreven en heeft een behoorlijk objectmodel waardoor het je toelaat om op een eenvoudige manier de behaviour te wijzigen naar je eigen wensen.

Absoluut een fan dus :-)

Kost het veel moeite/tijd om het goed onder de knie te krijgen?

Ik was er in korte tijd snel mee vertrokken, wat voorbeelden bestuderen en je bent er zo mee weg.

Mis je op ten duur bepaalde flexibiliteit, omdat bijvoorbeeld bepaalde code voor je wordt gegenereerd?

Niet echt, je kunt het volledig aanpassen aan je wensen. Echt code genereren doet het niet, geen scaffolding en toestanden dus

Hoe zit het wat betreft de performance, treed er veel performance verlies op?

Niks merkbaar, maar eigenlijk ook niet echt aandacht aan besteed.

Is er voldoende shared hosting hosting beschikbaar voor het betreffende framework (zo vereist Prado een bepaald aantal PHP extensies)?

Buiten de standaard extensions heb je volgens mij niks nodig. Ik gebruik het in elk geval op een standaard installatie.

Het zit het met de documentatie en de achterliggende communities? Is het voorgekomen dat je een groot probleem had, hoe is dat opgelost?

De documentatie voldoet meestal, maar in het begin vond ik die niet altijd up to date. Het enige grote probleem dat ik heb gehad was met Zend_Pdf.

Zijn er bepaalde knelpunten waar je tegenop liep?

Zend_Pdf dus

[MBV]

in hoeverre verschilt de functionaliteit van zo'n framework nou eigenlijk van PHP met Pear? Want _Pdf, _Db, dat soort dingen zit toch al lang in Pear?
Wat doet het qua performance?

[kokx]

PEAR bevat veel verschillende packages, die allemaal andere kwaliteiten hebben. Zo heb je PEAR::DB, PEAR::MDB, PEAR::MDB2. Maar Zend koppeld die packages aan elkaar waardoor je een zeer goede intuitieve interface hebt.

Zend is voor zijn directory structuur excact gelijk aan PEAR. Namelijk:
Path_To_Class
Dit wordt dan vertaald in:
Path/To/Class.php

Daarom beginnen alle classnames altijd met Zend_ (omdat volgens PEAR alles in de library moet staan met de naam van de package (Zend in dit geval) vooraan).

Als je een onderdeel in PEAR vind dat je niet in Zend vind kun je dat gewoon oplossen door deze naast Zend in je include path zet (gewoon dezelfde directory). Dat is wel het grootste nadeel aan Zend, het moet in je include path staan.

Performance staat niet zeer hoog in het vaandel bij Zend (net zoals alle frameworks). Maar de performance van Zend is duidelijk merkbaar hoger dan bij Symfony (daar moet je af en toe zo'n 4 min. wachten, gezien niet alles op dat moment in de cache van Symfony staat). Oftewel, er wordt gedacht aan performance, maar voorop staat gemak voor de programmeur (zolang dat niet te veel performance scheelt, zoals bij Symfony het geval is).

Edit: Je hebt nergens echt bepaalde extensies nodig. Al is het soms wel handig om een bepaalde extensie te gebruiken. Vooral bij Zend_Db is het handig als je PDO gebruikt. Gezien je met PDO SQL injections zo goed als onmogelijk kunt maken. En Zend_Db maakt daar met zijn functies handig gebruik van.

[ Voor 11% gewijzigd door kokx op 06-07-2007 15:54 ]

[MBV]

Klinkt goed. Over die performance: als je high performance nodig hebt, moet je geen PHP gebruiken (iig niet op linux), pak dan Java/Mono/..., PHP hangt echt onderaan het rijtje. Er zijn slechtere (http://shootout.alioth.de...ark.php?test=all&lang=all), maar als Java 100x zo snel is...

Blijft natuurlijk wel belangrijk dat het 'werkbaar' is. En als de performance hit niet te groot is, vind ik het de mindere ontwikkeltijd wel waard

[Anoniem: 34426]

MBV schreef op vrijdag 06 juli 2007 @ 16:02:
Klinkt goed. Over die performance: als je high performance nodig hebt, moet je geen PHP gebruiken (iig niet op linux), pak dan Java/Mono/..., PHP hangt echt onderaan het rijtje. Er zijn slechtere (http://shootout.alioth.de...ark.php?test=all&lang=all), maar als Java 100x zo snel is...

Blijft natuurlijk wel belangrijk dat het 'werkbaar' is. En als de performance hit niet te groot is, vind ik het de mindere ontwikkeltijd wel waard

Eventueel kun je php in fast-cgi mode draaien. Dan is het wel razend snel.

[Anoniem: 65297]

MBV schreef op vrijdag 06 juli 2007 @ 16:02:
Klinkt goed. Over die performance: als je high performance nodig hebt, moet je geen PHP gebruiken (iig niet op linux), pak dan Java/Mono/..., PHP hangt echt onderaan het rijtje. Er zijn slechtere (http://shootout.alioth.de...ark.php?test=all&lang=all), maar als Java 100x zo snel is...

Blijft natuurlijk wel belangrijk dat het 'werkbaar' is. En als de performance hit niet te groot is, vind ik het de mindere ontwikkeltijd wel waard

Is er voor die benchmarking enige optimizing gebruikt?

[kokx]

Waarschijnlijk niet, maar dat moet je nooit doen voor een bench. Vooral gezien niet iedere host optimaliseer progjes als Zend Optimizer heeft (mijn host bijvoorbeeld niet, aangezien het niet compatibel is met een bepaalde php-extensie).

[Anoniem: 65297]

Ok, dat is juist, maar op die manier heb je wel een soort van valse start van andere talen/platformen vermits die out of the box enige "caching" hebben.

[Mac_Cain13]

Interessant topic, ik heb zelf ook een poos gezocht naar het "perfecte" PHP framework. Uiteraard bestaat dat niet en heb ik het ook niet gevonden, maar waar ik erg tegen aanliep was vooral het model waar een framework je in dwingt.

Het is vaak net niet helemaal wat je wilt. Een opensource framework kun je dan aanpassen en je verbeteringen zelfs terug geven aan de community, maar uiteindelijk ben ik zelf begonnen een framework te ontwikkelen voor dat wat ik nodig had.

Zo heb ik niet teveel en niet te weinig functionaliteit en kan ik het in een oogwenk updaten en aanpassen. Maargoed het is de vraag of het voor jou uit kan zelf iets te maken. Dat is ook weer tijd die je allemaal moet investeren.

[Anoniem: 174951]

Ik ben momenteel een voor mijn begrippen grote back-end applicatie (zeer custom CMS) aan het bouwen in CakePHP. Voor ik begon had ik werkelijk 0,0 ervaring met dit framework. Ik moet zeggen dat het leren me vrij snel is afgegaan, en kom al na een aantal uren, prima lappen code schrijven zonder de documentatie erop na te slaan. Groot nadeel van Cake is de documentatie, deze is namelijk zeeeeeer beperkt, maar zodra je eenmaal gewend bent aan het "principe" kan je het redelijk af met alleen de API omschrijving en eventueel de google-group van Cake.

Groot voordeel van Cake t.o.v. CI vond ik (ondanks dat ik CI slechts ken van een paar kleine testen) is het in mijn ogen helderdere omgaan met views (in CI moet je ze laden, in Cake kan dat ook maar gaat automatisch indien je geen speciale wensen hebt), ook het omgaan met standaard templates vind ik iig in Cake erg eenvoudig, je hoeft in je views echt alleen maar de 'core' te maken, alle standaard rommel kan je dan in je default stoppen.

Vanuit mn beginnerservaring kan ik zeggen dat vooral het gebruik van Models echt een uitkomst is, je kan hierin eenvoudig de relaties tussen tabellen leggen waardoor query's doorwerken over de relaties. Je hoeft hierdoor in je controller slechts een findAll te doen waardoor je alle informatie krijgt die je normaal met joins zou krijgen. Nog mooier vind ik het deleten van rows, indien je dependancy aanzet, kan je door middel van 1 delete een totale cascade veroorzaken die zorgt dat de data-integriteit gewaarborgd blijft... (niets nieuws voor de ervaren framework gebruikers waarschijnlijk, maar wellicht interessant in de beginners zoals ikzelf)

[MBV]

Anoniem: 65297 schreef op vrijdag 06 juli 2007 @ 16:36:
[...]

Is er voor die benchmarking enige optimizing gebruikt?

Ik zeg niet dat voor jóuw applicatie PHP langzamer is, ik zeg dat in het algemeen berekeningen e.d. met PHP langzamer zijn dan berekeningen met Java. En ik denk dat zend optimizer die factor 150 langzamer wel kan terugbrengen, naar pak-em-beet factor 10

En ik denk dat optimizing bij Java ook wel het een en ander kan uitmaken
_{de code is trouwens te zien als je op 'php' klikt, en dan op de tests}

[ Voor 7% gewijzigd door MBV op 07-07-2007 10:17 ]

[Wim Leers]

Drupal! (PHP 4/5)

http://drupal.org/

Je kan wel niet vanaf 0 beginnen, je moet verder bouwen op de Drupal core, maar afhankelijk van de toepassingen die je bouwt is dat meestal geen probleem. Het mooie is dat er al zeer veel modules bestaan (ook behoorlijk wat crap bij, maar goed), die je kan hergebruiken, uitbreiden, wat dan ook.

API documentatie: htp://api.drupal.org
Documentatie: http://drupal.org/handbooks
Forum: http://drupal.org/forum
IRC channel voor developers: irc://irc.freenode.net#drupal

[Wim Leers]

MBV schreef op zaterdag 07 juli 2007 @ 10:17:
[...]

Ik zeg niet dat voor jóuw applicatie PHP langzamer is, ik zeg dat in het algemeen berekeningen e.d. met PHP langzamer zijn dan berekeningen met Java. En ik denk dat zend optimizer die factor 150 langzamer wel kan terugbrengen, naar pak-em-beet factor 10

En ik denk dat optimizing bij Java ook wel het een en ander kan uitmaken
_{de code is trouwens te zien als je op 'php' klikt, en dan op de tests}

Caucho Resin = native Java based PHP 5 interpreter

Die runt Drupal 3.5 tot 4 keer sneller dan Apache + PHP...

http://www.workhabit.org/...mance-improvements-drupal

[kokx]

Drupal is volgensmij een CMS, geen echt framework. Waarschijnlijk zal er dan ook niet echt de functionaliteit in zitten die je in een framework wilt, gezien de code toch op het CMS geörienteerd is.

[Xandrios]

Ik ben begonnen met CodeIgniter. In eerste instantie erg fijn, veel mogelijkheden. Ik kwam echter ook een 'probleem' tegen:

Een website heeft vaak herhaalde onderdelen. Denk aan een poll die op elke pagina getoond moet worden. Nu wil je de code van die poll uiteraard maar 1 maal implementeren. En daar komt je probleem.

Met CI wordt er vanuit gegaan dat je alle data 'klaarzet' in je controller, en dan doorpaast naar de view. De view doet niets anders dan het weergeven van deze data.

Als je nu een view maakt speciaal voor de Poll, en deze embed in je pagina's dan heb je het half werkende. Alleen wordt op die manier de data voor de poll niet automatisch verzameld, en dat zul je dan alsnog moeten doen op elke pagina. Das lastig.

Nu zie ik twee manieren om dit te fixen:
1) Maak een library die de gemeenschappelijke code voor de poll ed bevat. Deze include je op elke andere pagina.
2) Zorg dat de poll-view zelf een link heeft naar z'n model. Dan kun je simpelweg de view includen, en deze haalt zelf zijn benodigde waardes uit het model.

Beide heb ik getest, en beide werken ze technisch goed. ik vraag me alleen af welke het netste is, volgens MVC regels. Ik *meen* me te herinneren dat het acceptabel is dat de view een link heeft naar zijn model. Klopt dat?

[kokx]

Het netste van jouw keuzes is dat je het in de library zet. Als je deze code dan gebruikt op elke pagina is het het simpelste te implementeren. Maar wat eigenlijk nog correcter is, om deze code in de front controller + main view (view die op elke pagina wordt getoond, om de view zelf heen) te zetten.

[Anoniem: 49627]

Je kunt een framework inzetten om het framework, je kunt ook een framework inzetten omdat je tegen een probleem aanloopt wat dat framework voor je oplost. Alleen de laatste rechtvaardigt het gebruik van een framework. Het probleem is nogal behoorlijk onderbelicht in dit topic en toch wordt het probleem keurig benoemd in de start post. Heel fijn dat je iets lekker vind werken maar dat is echt een ternair argument.

Een goed framework neemt je werk uit handen. Een slecht framework benadert het probleem enkel anders (bijvoorbeeld smarty). Ik weet verder te weinig van de verschillende php frameworks dus ik kan niet de juiste eruit pikken die daadwerkelijk een probleem aanpakken. In ieder geval wordt de discussie een stuk zinniger als daar meer op gelet wordt

[Kalentum]

Herkenbaar probleem. Ik heb altijd bij bedrijven gewerkt die zelf al een framework hadden of waar de tijd was om dat zelf verder te ontwikkelen. Nu werk ik bij een niet-IT bedrijf en ben ik meer op mezelf aangewezen.

Voor een eenvoudige website met eigenlijk alleen maar een menu + wat teksten die daar aan moesten hangen heb ik gebruik gemaakt van CMS Made Simple (http://www.cmsmadesimple.org)

Ik ben nu bezig met een complexere site (met veel niet-standaard dingen) en daar had ik een framework voor nodig. Heb er verschillende bekeken en ze hebben allemaal hun eigen onhebbelijkheden. Verder stikt het van de frameworks, het is nog niet zo dat er 1 of een paar frameworks zijn boven komen drijven als zijnde 'de standaard', zoals bij Ruby (Rails) en Python (Django) wel is gebeurd. Dus het is lastig kiezen.

Het valt me op dat veel frameworks toch uitgaan van een simpele database structuur (bv dat er een relatie is tussen een model en een tabel). Wil je wat gekkers dan kan zo'n framework al in de weg staan.

Ik ben er nog niet helemaal uit maar ben nu bezig om CakePHP te testen. Code Ignitor zou ook nog wel kunnen.

[RAJH]

Anoniem: 49627 schreef op maandag 09 juli 2007 @ 09:49:
Je kunt een framework inzetten om het framework, je kunt ook een framework inzetten omdat je tegen een probleem aanloopt wat dat framework voor je oplost. Alleen de laatste rechtvaardigt het gebruik van een framework. Het probleem is nogal behoorlijk onderbelicht in dit topic en toch wordt het probleem keurig benoemd in de start post. Heel fijn dat je iets lekker vind werken maar dat is echt een ternair argument.

Een goed framework neemt je werk uit handen. Een slecht framework benadert het probleem enkel anders (bijvoorbeeld smarty). Ik weet verder te weinig van de verschillende php frameworks dus ik kan niet de juiste eruit pikken die daadwerkelijk een probleem aanpakken. In ieder geval wordt de discussie een stuk zinniger als daar meer op gelet wordt

Smarty vind ik niet echt een framework, omdat het alleen maar een template engine is. Ik gebruik op dit moment wel het Zend Framework voor een nieuw project, maar maak geen gebruik van de Zend_Controller omdat ik een andere structuur gewend ben.

Ik zet mijn projecten meestal als volgt op:

/public_html/<controller>.php
/public_html/inc/config.php // Met constants en includes
/public_html/inc/libs/ // Met libs zoals Zend, Smart, enz
/public_html/inc/templates/ // Met templates
/public_html/inc/classes/ // Met models

En als ik smarty gebruik komen de volgende dirs er nog bij
/public_html/inc/cache/ // Smarty Cache
/public_html/inc/configs/ // Smarty Configs
/public_html/inc/templates_c/ // Compiled Smarty Templates

Totdat ik natuurlijk weer een betere manier vind om het in te delen

[Anoniem: 49627]

RAJH schreef op maandag 09 juli 2007 @ 10:06:
Smarty vind ik niet echt een framework, omdat het alleen maar een template engine is. Ik gebruik op dit moment wel het Zend Framework voor een nieuw project, maar maak geen gebruik van de Zend_Controller omdat ik een andere structuur gewend ben.

Apart, wanneer is een stuk code een framework?

[RAJH]

Volgens wikipedia:

In software development, a Framework is a defined support structure in which another software project can be organized and developed. Typically, a framework may include support programs, code libraries and a scripting language amongst other software to help develop and glue together the different components of your project.

Dus volgensmij als het de meeste aspecten van een project kan ondersteunen.

Dat Smarty volgens de wikipedia definitie onder de frameworks valt lijkt mij vrij duidelijk

Ik zie smarty dus niet als een framework, maar als een code library. Dit omdat smarty alleen maar een template engine is en dus ook niet de meeste aspecten van een project ondersteund zoals Zend en CodeIgniter en dergelijke wel doen.

Onder een Framework versta ik een verzameling code libraries waarmee een hele website mee gebouwd kan worden. Dan denk ik aan DB, Mail, Cache en MVC libs samen.

offtopic:
Maar het bovenstaande zal per developer wel weer verschillen

[ Voor 41% gewijzigd door RAJH op 09-07-2007 13:22 ]

[Anoniem: 49627]

RAJH schreef op maandag 09 juli 2007 @ 10:39:
Volgens wikipedia:
Dus volgensmij als het de meeste aspecten van een project kan ondersteunen.

offtopic:
Ja ik weet wat de poging is die op wikipedia wordt gedaan om een framework te definieren, maar ik vroeg wat jouw definitie is. Dat Smarty volgens de wikipedia definitie onder de frameworks valt lijkt mij vrij duidelijk. Klaarblijkelijk vind je dat zelf niet

---

RAJH schreef op maandag 09 juli 2007 @ 10:39:

offtopic:
Ik zie smarty dus niet als een framework, maar als een code library. Dit omdat smarty alleen maar een template engine is en dus ook niet de meeste aspecten van een project ondersteund zoals Zend en CodeIgniter en dergelijke wel doen.

offtopic:
Dus omdat het niet de meeste aspecten van een project ondersteunt, mag het geen framework genoemd worden? Waar ligt dan de grens? Bij hoeveel aspecten is iets een framework?

"Zend en Codelgniter hebben beide geen out-of-the-box 'wizard form' functionalteit dus het zijn beide geen frameworks"

[ Voor 43% gewijzigd door Anoniem: 49627 op 09-07-2007 13:13 ]

[BikkelZ]

Ik zet mijn geld toch op Zend in. Het enige framework waar een grote speler echt zijn gewicht achter zet. En het is ook zo flexibel dat je bijvoorbeeld je eigen CMS kan gaan bouwen met Zend zonder dat je het gevoel krijgt iets te moeten cq. niet te kunnen of juist heel veel performance in moet leveren voor onnodige functies.

Ik zeg niet dat Zend nu beter is dan alle andere frameworks (ik ken ze zelfs niet eens allemaal), maar ik denk dat het uiteindelijk wel een hele duidelijke koppositie in gaat nemen. Ik ga het me in ieder geval helemaal meester maken.

[JKVA]

Hier staat een hele lijst:
http://www.phpwact.org/php/mvc_frameworks

Ik heb zelf ooit iets kleins met Mojavi gedaan. Dat beviel toen wel goed. Maar goed, mijn PHP framework ervaring is verder nihil.

Als ik deze lijst bekijk, dan ogen deze ook wel cool (qua concept tenminste)

• http://www.navphp.net/
  Ze beweren een IoC framework te zijn, en dat is op zich een goed concept. Documentatie is alleen op het eerste gezicht crap.
  LGPL license. Staat niet op de site zover ik kon zien, alleen in de readme.
• http://www.phpontrax.com/
  Ruby on Rails look-a-like. Code in de demo's oogt op zich best aardig.
  Gebaseerd op de BSD license http://svn.phpontrax.com/about

[ Voor 24% gewijzigd door JKVA op 09-07-2007 15:19 ]

[Icheb]

Even een bump van dit topic.

Op dit moment ben ik bezig met dingen in CakePHP en Code Igniter, maar dankzij een benchmark gisteren gaat het hele MVC framework idee toch maar overboord.

Op het moment dat de Apache Benchmarker werd losgelaten op de gemaakte code kwam daaruit dat de code MET code igniter ongeveer 9 pageviews per seconde kon trekken. Code zonder code igniter kwam uit op rond de 250 pageviews per seconde. Aangezien dit voor een frontend is waar erg veel hits op gaan komen, is besloten om Code Igniter maar te droppen. Even als note, dit probleem ligt niet aan de MySQL server, de PHP installatie of de servers. Deze zijn allen maximaal geoptimaliseerd.

Hoe is jullie ervaring in de snelheid van de verschillende frameworks?
Hebben jullie dezelfde ervaring waarbij het gebruik van frameworks sites significant lagere prestaties opleveren, of is bij jullie prestatie ondergeschikt aan de hoeveelheid servers die je ervoor nodig hebt en de manier van coden ?

[Optix]

En hoeverre had je CI al ingewijdt? oftewel had je er al een 'heel systeem' op draaien of ... ?

Heb net een ab command op mijn eigen framework losgelaten. Haalde 33 RPS (Requests per second) op een versie waar al een vrij groot systeem op draait. Een 'gewone pagina' 500 RPS.

Als ik zo naar ^^^^ kijk over CI (afhankelijk van zijn antwoord op mijn eerste vraag) is dat dus 'best wel' netjes.

Verder vind ik CakePHP al weer langzaam vergeleken met CI destijds.

Ik denk dat het probleem zit in het feit dat veel frameworks toch nog te veel dingen laden.
Zonder dat je kan aangeven, dit, dit en dit wil ik niet laden want dat heb ik toch niet nodig.

[WouZz]

Icheb schreef op vrijdag 03 augustus 2007 @ 10:13:
Op het moment dat de Apache Benchmarker werd losgelaten op de gemaakte code kwam daaruit dat de code MET code igniter ongeveer 9 pageviews per seconde kon trekken. Code zonder code igniter kwam uit op rond de 250 pageviews per seconde.

Dat is wel een groot verschil. Weet je ook waar de bottleneck ligt? Op zich is CI niet zo zwaar. Het zijn maar een paar classes en functies die worden aangeroepen. Had je een .htaccess voor je rewrite rules? Misschien dat die voor overhead zorgen?

Wij gebruiken iig ook veel code-igniter in productie omgeving, maar volgens mij hebben we deze nooit echt aan een relatieve snelheidstest onderworpen.

[MBV]

Waarom kijk je niet met zend debugger ofzo waar de bottleneck ligt? Er zijn sowieso 3 profilers voor PHP, waarvan 2 met een GPL-achtige licentie. Zeker met een GPL-framework kan je die bottleneck vervolgens slopen

Het voordeel van een framework kan zijn dat het door caching sneller kan worden dan zonder framework. _{En dat een goed ontworpen framework sneller is dan een bagger-framework wat door een prutser zelf is geschreven}

[ Voor 50% gewijzigd door MBV op 03-08-2007 16:06 ]

[Icheb]

Als ik er nog wat tijd voor kan vinden, wil ik zeker nog wel even kijken morgen waar precies de traagheid zit in CI.

Want ik ben er niet bepaald blij mee dat er nu 'een hele week' is ingeplant voor het maken van een eigen framework. Ik vraag me af of we met zo'n korte tijd niet nog meer fouten gaan maken. Maar goed, ook al kunnen we CI sneller krijgen, vraag ik me af of het genoeg is. Het zal tot minimaal 35 requests per seconde moeten gaan, wilt CI nog een kans maken...

.htacces is best wel, ehm, ongeveer verplicht om het goed te laten werken .
Dus ja, die was aanwezig.

MBV schreef op vrijdag 03 augustus 2007 @ 16:05:
...
Het voordeel van een framework kan zijn dat het door caching sneller kan worden dan zonder framework. _{En dat een goed ontworpen framework sneller is dan een bagger-framework wat door een prutser zelf is geschreven}

Caching zou er in dat nieuwe framework ook in moeten komen.
Niet dat we een team met prutsers zijn, maar ik geloof er inderdaad niet in dat we in een week een goedwerkend framework kunnen maken...

[kokx]

Een goed framework moet (naar mijn mening) in goed OOP zijn geschreven en redelijk wat performance leveren.

En trouwens, met wat voor pagina heb je het zitten testen, was het veel inhoud, of gewoon een paar regeltjes code? Want dat maakt heel veel uit.

Maar ik raad je het schrijven van een eigen framework niet aan. Een fatsoenlijk framework is enorm veel werk.

Verder, de grootste bottleneck van de meeste frameworks licht bij het includen van alle files. Je zou dus een lijst kunnen maken met alle files van classes die je gebruikt en deze met een scriptje bij elkaar in 1 file proppen, dan heb je denk ik ook al veel gewonnen.

[MBV]

Da's wel een goeie: ik heb gehoord van iemand die alle require_once aanroepen heeft vervangen door aanroepen naar een singleton-klasse die dat bijhield. Werkte een stuk sneller.

Wat ook heel veel tijd kost in PHP: constants declareren, iets wat lastiger achteraf is aan te passen.

[BikkelZ]

kokx schreef op donderdag 09 augustus 2007 @ 09:35:
Maar ik raad je het schrijven van een eigen framework niet aan. Een fatsoenlijk framework is enorm veel werk.

Ik ben de laatste tijd aan het solliciteren, en ik merk gewoon dat iedere toko zijn eigen fantastische frameworkje heeft gebouwd. Allemaal. Weer. Opnieuw. Een eigen. Framework.

Als ik alleen al in de regio Eindhoven kijk hoeveel manjaar er verspild is doordat iedereen het zelfde gedaan heeft, dan ben ik als programmeur zijnde slechts blij dat er op kunstmatige wijze eigenlijk zo'n tekort aan programmeurs gecreëerd wordt.

kokx schreef op donderdag 09 augustus 2007 @ 09:35:Verder, de grootste bottleneck van de meeste frameworks licht bij het includen van alle files. Je zou dus een lijst kunnen maken met alle files van classes die je gebruikt en deze met een scriptje bij elkaar in 1 file proppen, dan heb je denk ik ook al veel gewonnen.

Ik werd laatst bijna levend gefileerd hier toen ik opperde dat veel includes PHP scripts traag maakte, want de optimizers zouden compleet met die disk-access penalty afrekenen

[kokx]

BikkelZ schreef op donderdag 09 augustus 2007 @ 11:58:
[...]


Ik ben de laatste tijd aan het solliciteren, en ik merk gewoon dat iedere toko zijn eigen fantastische frameworkje heeft gebouwd. Allemaal. Weer. Opnieuw. Een eigen. Framework.

Als ik alleen al in de regio Eindhoven kijk hoeveel manjaar er verspild is doordat iedereen het zelfde gedaan heeft, dan ben ik als programmeur zijnde slechts blij dat er op kunstmatige wijze eigenlijk zo'n tekort aan programmeurs gecreëerd wordt.


[...]


Ik werd laatst bijna levend gefileerd hier toen ik opperde dat veel includes PHP scripts traag maakte, want de optimizers zouden compleet met die disk-access penalty afrekenen

Hier is het juist andersom, hier gooien we alles veel liever in 1 file, gaat gewoon veel sneller. Ook met die optimizers erbij hoor .

En hier gebruiken we ook niet een eigen framework, maar Zend. Hier staat eerder voorop dat wij hoge productiviteit hebben. Daardoor kent iedereen hier Zend zo goed als uit zijn hoofd.

[Grijze Vos]

BikkelZ schreef op donderdag 09 augustus 2007 @ 11:58:
[...]

Ik werd laatst bijna levend gefileerd hier toen ik opperde dat veel includes PHP scripts traag maakte, want de optimizers zouden compleet met die disk-access penalty afrekenen

Zou ook zo moeten zijn. Als dat niet zo is dan moet er nog flink aan die optimizers gewerkt worden.

[kokx]

Grijze Vos schreef op donderdag 09 augustus 2007 @ 12:16:
[...]

Zou ook zo moeten zijn. Als dat niet zo is dan moet er nog flink aan die optimizers gewerkt worden.

Het zou ook zo moeten zijn ja, maar het zal ook altijd zo zijn dat alles in 1 file sneller hoort te werken dan 500 verschillende files. En als je denkt 'de optimizer regelt dat wel' dan vind ik dat je als programmeur een foute instelling hebt.

[SchizoDuckie]

kokx schreef op donderdag 09 augustus 2007 @ 12:34:
[...]

Het zou ook zo moeten zijn ja, maar het zal ook altijd zo zijn dat alles in 1 file sneller hoort te werken dan 500 verschillende files. En als je denkt 'de optimizer regelt dat wel' dan vind ik dat je als programmeur een foute instelling hebt.

Dat lijkt mij best wel BS eigenlijk...

Waarom zou 1 grote file met 100 verschillende classes erin sneller zijn dan een __autoload() die alleen de 5 á 10 juiste classes hoeft te inladen
Die ene grote file moet wel eerst even lekker door de stack parser heen en compleet in 't geheugen gedumpt worden...

Verder ben je imo niet goed bij je hoofd als je alles in 1 grote file dumpt. dat zal lekker debuggen zijn zeg

[ Voor 8% gewijzigd door SchizoDuckie op 09-08-2007 12:44 ]

[kokx]

SchizoDuckie schreef op donderdag 09 augustus 2007 @ 12:43:
[...]


Dat lijkt mij best wel BS eigenlijk...

Waarom zou 1 grote file met 100 verschillende classes erin sneller zijn dan een __autoload() die alleen de 5 á 10 juiste classes hoeft te inladen
Die ene grote file moet wel eerst even lekker door de stack parser heen en compleet in 't geheugen gedumpt worden...

Verder ben je imo niet goed bij je hoofd als je alles in 1 grote file dumpt. dat zal lekker debuggen zijn zeg

In development houden we alles gewoon gescheiden in files. Maar later in production gooien we ook niet alles bij elkaar. Maar zetten we files die eigenlijk altijd in combinatie geinclude moeten worden bij elkaar. De production versie is overigens wel database-afhankelijk (wij includen bij Zend_Db meteen Zend_Db_Adapter_Pdo_Mysql). En in development is dat weer niet zo.

[SchizoDuckie]

kokx schreef op donderdag 09 augustus 2007 @ 13:06:
[...]

In development houden we alles gewoon gescheiden in files. Maar later in production gooien we ook niet alles bij elkaar. Maar zetten we files die eigenlijk altijd in combinatie geinclude moeten worden bij elkaar. De production versie is overigens wel database-afhankelijk (wij includen bij Zend_Db meteen Zend_Db_Adapter_Pdo_Mysql). En in development is dat weer niet zo.

Dat zijn dan dus eigenlijk gewoon weer micro-optimalisaties

[Grijze Vos]

Het lijkt mij dat een zinnige optimizer toch gewoon die files cached in het werkgeheugen? Heb zelf nooit met optimizers gewerkt, maar dat leek me logisch. Zo doet mod_python het iig ook.

[ Voor 8% gewijzigd door Grijze Vos op 09-08-2007 13:41 ]

[BikkelZ]

kokx schreef op donderdag 09 augustus 2007 @ 12:15:
[...]

Hier is het juist andersom, hier gooien we alles veel liever in 1 file, gaat gewoon veel sneller. Ook met die optimizers erbij hoor .

Ik heb het idee dat er een hoop aannames bestaan en weinig harde gegevens op dit vlak. Ik geloof graag dat 500 files of 1 file met dezelfde code net zo snel is mits ik generiek een optimizer of specifiek optimizer x gebruik, maar ik ben er nog niet van overtuigd door een geloofwaardige test ergens.

kokx schreef op donderdag 09 augustus 2007 @ 12:15:
[...]En hier gebruiken we ook niet een eigen framework, maar Zend. Hier staat eerder voorop dat wij hoge productiviteit hebben. Daardoor kent iedereen hier Zend zo goed als uit zijn hoofd.

Nou ja je bouwt denk ik wel weer wat bovenop Zend qua classes, ik noem maar een dwarsttraat, bijvoorbeeld een class die Nederlandse adressen kan checken t.o.v. een Cendris database, CMS-achtige dingen, etcetera. Zend is toch nog redelijk low-level natuurlijk (en gelukkig maar misschien), en daar bovenop komen je eigen dingen óf een kant-en-klaar iets.

[kokx]

Grijze Vos schreef op donderdag 09 augustus 2007 @ 13:19:
Het lijkt mij dat een zinnige optimizer toch gewoon die files cached in het werkgeheugen? Heb zelf nooit met optimizers gewerkt, maar dat leek me logisch. Zo doet mod_python het iig ook.

Dit werkt goed als je een dedicated server hebt. Maar als je met een gewone webhost zit, kunnen ze daar echt niet je hele framework in het werkgeheugen gooien. Want er zijn meerdere scripts die moeten draaien, en ook nog eens andere applicaties die veel werkgeheugen nodig zullen hebben.

BikkelZ schreef op donderdag 09 augustus 2007 @ 13:42:
[...]


Nou ja je bouwt denk ik wel weer wat bovenop Zend qua classes, ik noem maar een dwarsttraat, bijvoorbeeld een class die Nederlandse adressen kan checken t.o.v. een Cendris database, CMS-achtige dingen, etcetera. Zend is toch nog redelijk low-level natuurlijk (en gelukkig maar misschien), en daar bovenop komen je eigen dingen óf een kant-en-klaar iets.

We gebruiken mijn project ZendExt en nog een aantal specifieke classes voor elke applicatie (zoals een eigen Auth adapter, en nog meer van zulke dingen). Want elke applicatie vraagt natuurlijk net een aantal andere dingen. En inderdaad, daar is Zend een perfect framework voor, het is geschreven met het ook op uitbreiding.

[ Voor 9% gewijzigd door kokx op 09-08-2007 14:05 ]

[BastiaanN]

*schopt topic weer omhoog

Ik merk de laatste maanden toch echt wel weer dat ik telkens het wiel opnieuw loop uit te vinden, voor mijn eigen bedrijf wil ik graag een cms maken omdat veel opensource cmsjes gewoon weer nodeloos complex zijn opgebouwd en door mensen die niet dagelijks achter de computer zitten gewoon niet worden begrepen totdat je er 2 dagen uitleg aan hebt besteed, dat moet toch anders kunnen?

Telkens als ik projecten begin betrap ik mijzelf vaak weer op het schrijven van dezelfde code als andere mensen, de ene klant wil een fotoboek ala X en de ander wil weer een fotoboek ala C en dat haalt voor mij toch wel het plezier uit het programmeren omdat je dan -zoals ik al eerder zei- het gevoel hebt dat je het wiel opnieuw loopt uit te vinden. Het even "snel" schrijven van een leuk fotoboek vind ik geen probleem maar vaak ben je er toch weer langer mee bezig dan dat eigenlijk je bedoeling is/was omdat de functies die je al eens voor een andere klant hebt geschreven toch niet helemaal voldoen aan je eisen.

Het punt is eigenlijk dat ik graag wil leren werken met een goed framework zonder dat de performance daar erg onder gaat lijden. Ik heb verder 0,0 ervaring met frameworks en wil eigenlijk via deze weg vragen of een framework ook daadwerkelijk een goede oplossing is voor mijn probleem. Met oplossing bedoel ik niet dat ik een compleet fotoboek uit een framework kan trekken maar dat het schrijven ervan stukken sneller en efficiënter kan. En zoja, welk framework kan ik dan het beste gaan gebruiken?

[Grijze Vos]

Praat me er niet van. Ik ben net slachtoffer geworden van het typo3 framework, een extreem log framework met extreem ranzige code waarvan we twee relatief kleine sites onder beheer hebben genomen. Kan niet wachten tot ik de green light krijg om die twee sites te converteren naar .NET sites.

Letterlijk 1500 regels code nodig hebben voor iets wat ik in 15 regels asp.NET en 2 regels C# kan doen. Fijn om te debuggen.

----

De keuze van een framework is redelijk persoonlijk. Trek een paar uit de kast, en kijk wat je bevalt. Ze hebben allemaal voors en tegens.

[ Voor 33% gewijzigd door Grijze Vos op 08-04-2009 11:23 ]

[Cartman!]

Dingen als Joomla/Drupal (Typo3 ook zover ik weet) zijn naar mijn idee ook niet echt n framework maar CMS-en die je zelf kunt uitbouwen met plugins/modules. Zelf werk ik nu een jaar in Zend Framework, daarin bouw je in feite wel alles zelf maar alleen de logica die nodig is voor je applicatie. Het werkt erg snel en als je iets dubbel moet schrijven dan maak je er een 'helper' van of grotere dingen zet je in een eigen library.

Andere bekende frameworks zijn bijv. CodeIgniter, Symphony en CakePHP. Check hun sites gewoon eens en kijk of dat je bevalt. Het ene framework duwt je 100% in een bepaalde richting terwijl een ander (Zend) je weer vrij laat in structuur of het zelfs toestaat losse componenten te gebruiken.

[Polichism]

Met codeigniter vind ik vooral vervelend dat je application dir in je systemdir moet zitten.
Kijk voor de grap eens naar Kohana en is btw ook uitgebreider dan Codeigniter.
Zelf ben ik erg fan van Zend framework

[BikkelZ]

Het probleem met PHP is gewoon dat de taal noch het platform niet in het bijzonder geschikt is voor complexere zaken. Om een hoger niveau van herbruikbaarheid te bereiken moet je simpelweg iets gebruiken wat zich daar wel voor leent, zoals Java of C# / .Net. Loose typed is alleen de eerste 1000 regels leuk, daarna gaat het tegen je werken.

Dingen als Zend FW blijven natuurlijk altijd welkom voor het platform, alleen al omdat het een standaard is.

[raptorix]

BikkelZ schreef op woensdag 08 april 2009 @ 16:59:
Het probleem met PHP is gewoon dat de taal noch het platform niet in het bijzonder geschikt is voor complexere zaken. Om een hoger niveau van herbruikbaarheid te bereiken moet je simpelweg iets gebruiken wat zich daar wel voor leent, zoals Java of C# / .Net. Loose typed is alleen de eerste 1000 regels leuk, daarna gaat het tegen je werken.

Dingen als Zend FW blijven natuurlijk altijd welkom voor het platform, alleen al omdat het een standaard is.

Dit dus, ik heb zelf ook lang in asp gewerkt, al die problemen die hier boven worden genoemd los je op de lange termijn niet op door een framework te gebruiken. Gebruik nu al weer heel wat jaartjes C# /.NET en dan merk je dat zaken zoveel makkelijker ontwikkelen.

[BastiaanN]

raptorix schreef op woensdag 08 april 2009 @ 17:15:
[...]

Dit dus, ik heb zelf ook lang in asp gewerkt, al die problemen die hier boven worden genoemd los je op de lange termijn niet op door een framework te gebruiken. Gebruik nu al weer heel wat jaartjes C# /.NET en dan merk je dat zaken zoveel makkelijker ontwikkelen.

Akkoord, maar wij kunnen nu eenmaal niet verwachten van al onze klanten dat ze .NET gaan draaien. Verder hoeven alle problemen ook niet opgelost te worden zolang het maar iets minder tijdrovend wordt om applicaties te schrijven.

[marco_balk]

Wij werken hier met een relatief jong en onbekend PHP framework: Konsolidate.
Al onze projecten zijn afgelopen 2 jaar zijn hiermee ontwikkeld. Mede door dit framework zijn we zo'n 10% efficienter/sneller gaan werken gedurende de projecten.

[Grijze Vos]

Cartman! schreef op woensdag 08 april 2009 @ 11:34:
Dingen als Joomla/Drupal (Typo3 ook zover ik weet) zijn naar mijn idee ook niet echt n framework maar CMS-en die je zelf kunt uitbouwen met plugins/modules.

Mja, ligt een beetje aan wat je definitie van een framework is. Een CMS met plugin functionaliteit kun je zien als een redelijk "dik" framework. Soms is er niks mis met een framework dat wat extra dingen voor je regelt, als je toch altijd die dingen nodig hebt.

kwakkie schreef op donderdag 09 april 2009 @ 05:45:
Wij werken hier met een relatief jong en onbekend PHP framework: Konsolidate.
Al onze projecten zijn afgelopen 2 jaar zijn hiermee ontwikkeld. Mede door dit framework zijn we zo'n 10% efficienter/sneller gaan werken gedurende de projecten.

10% vind ik niet echt veel hoor. Ik moet zeggen dat ik het met de posters boven je eens ben. PHP is een leuke taal waar je leuke dingen mee kunt doen, maar op een gegeven moment houdt het op en moet je gewoon naar andere talen gaan kijken als je grotere projecten hebt. Een framework rekt die grens op, misschien rekt het die grens wel heel veel op, maar ergens stopt het gewoon.

[flashin]

Grijze Vos schreef op woensdag 08 april 2009 @ 11:20:Letterlijk 1500 regels code nodig hebben voor iets wat ik in 15 regels asp.NET en 2 regels C# kan doen. Fijn om te debuggen.

Ik ken typo3 niet, maar dat lijkt me dan weer erg grote kwats natuurlijk

[MBV]

Ik denk dat er een feature is die standaard in het C#.NET framework zit, en niet in Typo3. En ik denk dat de getallen iets overdreven zijn, maar dat er wel een kern van waarheid in zit

[ Voor 35% gewijzigd door MBV op 09-04-2009 11:30 ]

[Grijze Vos]

Ik -wou- dat ik overdreef. Hier:

code:

$:~/www/typo3conf$ ~/bin/wcr.sh -l .
666326  Total

wcr.sh is een tooltje dat recursief /usr/bin/wc toepast. (wordcount, voor de niet-linuxers).
conclusie: alleen de folder met configuratie bestanden is al 666K regels lang. (Ok, hij telt hier wel .gif bestandjes e.d. mee die een klein percentage van het totaal afsnoepen.)

(library folder: 160K)
(typo3 folder: 450K)

Bijna elke entiteit die je in de admin interface open trekt heeft minstens 200 regels configuratie variables.

[ Voor 32% gewijzigd door Grijze Vos op 09-04-2009 12:08 ]

[MBV]

Simpele manier:

find -iname "*.php" |xargs wc -l 

Dan krijg je het aantal regels voor alle PHP-bestanden.

[Kalentum]

Grijze Vos schreef op donderdag 09 april 2009 @ 12:02:
Ik -wou- dat ik overdreef. Hier:

code:

$:~/www/typo3conf$ ~/bin/wcr.sh -l .
666326  Total

wcr.sh is een tooltje dat recursief /usr/bin/wc toepast. (wordcount, voor de niet-linuxers).
conclusie: alleen de folder met configuratie bestanden is al 666K regels lang. (Ok, hij telt hier wel .gif bestandjes e.d. mee die een klein percentage van het totaal afsnoepen.)

(library folder: 160K)
(typo3 folder: 450K)

Bijna elke entiteit die je in de admin interface open trekt heeft minstens 200 regels configuratie variables.

Een testsite van typo3 bekijkend kom ik tot de conclusie dat de elke module in de directory typo3conf/ext staat. Dus in jouw totaal staat de complete backend van alle typo3 moduels op die site die je als voorbeeld neemt (templates, functies, sql scripts, graphics).

De conclusie dat alleen de configuratie 666K regels bevat klopt niet. Hiervoor zou je alleen de directory typo3conf moeten pakken en niet de subdirectories.

Om wat voor soort typo3 - applicatie gaat het?

Verder is Typo3 nou niet iets wat ik als een framework zou zien. Typo3 is een CMS waar je modules voor kan schrijven, net zoals je Wordpress kan uitbreiden met je eigen dingen. T'is alleen wat ingewikkelder dan het gemiddelde CMS (en vaak overkill).

[Grijze Vos]

rutgerw schreef op donderdag 09 april 2009 @ 13:29:
[...]


Een testsite van typo3 bekijkend kom ik tot de conclusie dat de elke module in de directory typo3conf/ext staat. Dus in jouw totaal staat de complete backend van alle typo3 moduels op die site die je als voorbeeld neemt (templates, functies, sql scripts, graphics).

De conclusie dat alleen de configuratie 666K regels bevat klopt niet. Hiervoor zou je alleen de directory typo3conf moeten pakken en niet de subdirectories.

Om wat voor soort typo3 - applicatie gaat het?

Verder is Typo3 nou niet iets wat ik als een framework zou zien. Typo3 is een CMS waar je modules voor kan schrijven, net zoals je Wordpress kan uitbreiden met je eigen dingen. T'is alleen wat ingewikkelder dan het gemiddelde CMS (en vaak overkill).

Dat is nou juist mijn kritiek. (Configuratie van de modules hoort ook bij de configuratie.) Het gaat om een eenvoudige site met pak em beet 20 content pagina's gebaseerd op 1 template, een nieuws module, en nog wat extra functionaliteit die redelijk eenvoudig te implementeren is. Vervolgens bevat deze installatie bijna 100 modules waarvan ik niets durf aan te raken want je weet niet wat je stuk maakt als je iets deinstalleert wat je niet nodig denk te hebben.

Het is gigantisch overkill voor deze site, maar ik zou het systeem niet eens durven/willen gebruiken voor grote sites, want met zo'n kleine site is het al niet te overzien. Wij hebben dit pakket ook maar zo in de schoot geworpen gekregen omdat de klant geen inhouse beheer meer wilt doen omdat dat te duur is. In de tijd die het me heeft gekost om alles werkend te krijgen had ik die site gewoon kunnen bouwen in ons eigen .NET framework hier.

Sorry hoor, maar anderhalf a twee miljoen regels code voor een site als dit is gewoon dikke onzin. Zo uit het blote hoofd heeft mijn eigen (stokoude) php site (cms+news+forum en nog wat andere dingetjes) een regel of 15K ofzo. En dat biedt minstens twee keer zoveel functionaliteit.

Maar goed, trek eens een module open zou ik zeggen. Of probeer eens uit te zoeken waar de base URI wordt geset. Kostte mij net namelijk een uur om dat te vinden.

[Kalentum]

Is je kritiek nu dat frameworks overkill zijn of dat typo3 overkill is?

[Grijze Vos]

typo3

Wie developed tegenwoordig nou niet zonder een fatsoenlijk framework? (Op hobby-projecten na dan.)

[MBV]

@Grijze vos:is jouw kritiek dat Typo3 te generiek is, en dat jij te veel details te weten kan komen? de .NET code zit verstopt in het framework, als je 2 regels code neerzet en een beetje configuratie heb je al een half CMS. Daar zitten duizenden regels code achter, en talloze modules die je niet gebruikt. Maar omdat dat verstopt zit in binaries zie je het niet.

Als ik een Joomla site binnenkrijg met veel customizations (Typo3 ken ik niet), dan download ik joomla van die versie en doe ik een diff tussen de 2 directories. Zo zie je wat iemand heeft zitten uitbreiden/aanpassen, en wat er standaard is.

De opzet van opensource CMS'en zou inderdaad anders kunnen/moeten om wijzigingen t.o.v. standaard zichtbaar te maken. Maar waarom zou je alle standaard onderdelen, die net zo als plugin werken als jouw eigen plugin, apart houden?

[BikkelZ]

MBV schreef op donderdag 09 april 2009 @ 17:34:
@Grijze vos:is jouw kritiek dat Typo3 te generiek is, en dat jij te veel details te weten kan komen? de .NET code zit verstopt in het framework, als je 2 regels code neerzet en een beetje configuratie heb je al een half CMS. Daar zitten duizenden regels code achter, en talloze modules die je niet gebruikt. Maar omdat dat verstopt zit in binaries zie je het niet.

Tja maar het is wel een goed getest framework met alle support die ik maar kan wensen, en het wordt allemaal van te voren gecompileerd dus nauwelijks een performance hit vergeleken met PHP frameworks. Kijk in principe zijn al die in C gebakken functies ook allemaal onderdeel van een rudimentair geprecompileerd framework. Maar dat wordt allemaal nauwelijks meer geupdate.

Laat iemand eens in die stijl een framework bouwen, met dingen als een GridView en al die handige features er al in, voorgecompileerd en keihard gegarandeerd en ondersteund zdoor Zend. THen we're talking.

[MBV]

dat gaat nooit gebeuren, omdat dat niet voor een appel en een ei gehost kan worden. Veiligheidsrisico's voor het achterliggende OS als je binary code neer kan zetten, platformafhankelijk, dat soort dingen. Hét voordeel van PHP is juist dat het enige wat je neer dumpt een setje .php bestanden, en meer niet.

[BikkelZ]

Ja maar die PHP bestanden spreken uiteindelijk ook weer een stel binaries aan. Die binaries komen van Zend en die zijn min of meer gegarandeerd ondersteund en veilig. Als je aan die libraries een OO-based .Net of Java achtige library van classes toevoegt dan is dat dus standaard voor iedere PHP installatie. Net als Pear in principe.

[WouZz]

Helaas is het aanmaken van objecten in PHP nog relatief langzaam. Zend Framework is een mooi begin, maar nog lang geen standaard. Je ziet wel dat PHP / Zend vooruitgang boekt en steeds meer 'enterprise' wordt. Maar het zou echt mooi zijn als eindelijk die namespaces eens common zijn en er bijvoorbeeld ondersteuning voor packages en return types zou komen. Verder zou ik Zend Server wel eens in productie willen zien en dat vergelijken met een standaard LAMP stack.

[Anoniem: 274606]

Grijze Vos schreef op donderdag 09 april 2009 @ 10:18:
[...]

Mja, ligt een beetje aan wat je definitie van een framework is. Een CMS met plugin functionaliteit kun je zien als een redelijk "dik" framework. Soms is er niks mis met een framework dat wat extra dingen voor je regelt, als je toch altijd die dingen nodig hebt.


[...]

10% vind ik niet echt veel hoor. Ik moet zeggen dat ik het met de posters boven je eens ben. PHP is een leuke taal waar je leuke dingen mee kunt doen, maar op een gegeven moment houdt het op en moet je gewoon naar andere talen gaan kijken als je grotere projecten hebt. Een framework rekt die grens op, misschien rekt het die grens wel heel veel op, maar ergens stopt het gewoon.

Zolang je core business web-applicaties in de ruimste zin van t woord is ben ik dit absoluut niet met je eens. Dan is er bijna geen grens juist....

[Anoniem: 318007]

Hoe is de stand van zaken anno 2011 op dit terrein?

*Commentaar op moderatie mag je in Feedback op moderatie binnen de Devschuur kwijt*

[ Voor 67% gewijzigd door MueR op 05-01-2011 15:41 ]

[MueR]

Een twee jaar oud topic schoppen lijkt me in dit geval een beetje overbodig. Probeer de tips uit Het algemeen beleid #quickstart eens om een eigen topic te starten.