Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[PHP] Framework

Pagina: 1
Acties:
  • 5.170 views sinds 30-01-2008

Onderwerpen


  • gast
  • Registratie: juli 2001
  • Niet online

gast

Did you mean: dataquest

Topicstarter
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:
quote:
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
  • Registratie: mei 2007
  • Laatst online: 01-01-2017
*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. :P 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
  • Registratie: augustus 2001
  • Niet online
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
  • Registratie: februari 2002
  • Laatst online: 18-06 16: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?

  • gabberatski
  • Registratie: juli 2000
  • Laatst online: 10-05-2008
Kijk ook toch eens naar Symfony Project. Dat is zowat RoR in php


www.symfony-project.com

  • aex351
  • Registratie: juni 2005
  • Laatst online: 07:39

aex351

I am the one

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.

< dit stukje webruimte is te huur >


  • ibmos2warp
  • Registratie: januari 2007
  • Laatst online: 02-02 11:07

ibmos2warp

Eval is Evil

quote:
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 :X. En Joomla wordt ook (dacht ik) niet op een framework gebouwd.

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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 :P (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.

kokx wijzigde deze reactie 05-07-2007 20:03 (3%)


  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
quote:
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?
quote:
ibmos2warp schreef op donderdag 05 juli 2007 @ 19:33:
[...]

Joomla is geen framework :X. En Joomla wordt ook (dacht ik) niet op een framework gebouwd.
Goh, echt :?

:P

  • ibmos2warp
  • Registratie: januari 2007
  • Laatst online: 02-02 11:07

ibmos2warp

Eval is Evil

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

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


  • Optix
  • Registratie: maart 2005
  • Laatst online: 15-01 15:07
Hij bedoeld hoe/of andere projecten (dus niet frameworks :)) een framework toepassen.

.


  • gast
  • Registratie: juli 2001
  • Niet online

gast

Did you mean: dataquest

Topicstarter
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
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

@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
  • Registratie: maart 2005
  • Laatst online: 15-01 15:07
quote:
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 :Y)

.


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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


Vind ik wel een beetje minimaal wat ik van een beetje DB class verwacht hoor :Y)
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
  • Registratie: januari 2007
  • Laatst online: 02-02 11:07

ibmos2warp

Eval is Evil

quote:
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) :/

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


  • Pete
  • Registratie: november 2005
  • Laatst online: 28-05 21:34
quote:
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.

petersmit.eu


  • Optix
  • Registratie: maart 2005
  • Laatst online: 15-01 15:07
quote:
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 :r
quote:
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.

Optix wijzigde deze reactie 05-07-2007 22:45 (32%)

.


Acties:
  • 0Henk 'm!

  • dis.pater
  • Registratie: september 2002
  • Laatst online: 22-01-2014
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 :-)
quote:
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.
quote:
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 :)
quote:
Hoe zit het wat betreft de performance, treed er veel performance verlies op?
Niks merkbaar, maar eigenlijk ook niet echt aandacht aan besteed.
quote:
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.
quote:
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.
quote:
Zijn er bepaalde knelpunten waar je tegenop liep?
Zend_Pdf dus :)

Acties:
  • 0Henk 'm!

  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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?

Acties:
  • 0Henk 'm!

  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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.

kokx wijzigde deze reactie 06-07-2007 15:54 (11%)


Acties:
  • 0Henk 'm!

  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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 :)

Acties:
  • 0Henk 'm!

  • Kritz
  • Registratie: september 2001
  • Laatst online: 17-06 22:16
quote:
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.

Acties:
  • 0Henk 'm!

  • dis.pater
  • Registratie: september 2002
  • Laatst online: 22-01-2014
quote:
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?

Acties:
  • 0Henk 'm!

  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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).

Acties:
  • 0Henk 'm!

  • dis.pater
  • Registratie: september 2002
  • Laatst online: 22-01-2014
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.

Acties:
  • 0Henk 'm!

  • Mac_Cain13
  • Registratie: juni 2003
  • Laatst online: 01-06 10:47
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.

Acties:
  • 0Henk 'm!

  • Bo-oz
  • Registratie: mei 2006
  • Laatst online: 02-01-2018
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
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
quote:
dis.pater 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

MBV wijzigde deze reactie 07-07-2007 10:17 (7%)


  • Wim Leers
  • Registratie: januari 2004
  • Laatst online: 00:27
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
  • Registratie: januari 2004
  • Laatst online: 00:27
quote:
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
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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.

Acties:
  • 0Henk 'm!

  • Xandrios
  • Registratie: februari 2001
  • Laatst online: 21:09
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?

Acties:
  • 0Henk 'm!

  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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.

Acties:
  • 0Henk 'm!

  • mark platvoet
  • Registratie: februari 2002
  • Laatst online: 19-08-2010

mark platvoet

Moutarde apres le diner

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 :)

Religion has no place in public schools the way facts have no place in organized religion


Acties:
  • 0Henk 'm!

  • rutgerw
  • Registratie: juni 2004
  • Laatst online: 20:20
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.

Acties:
  • 0Henk 'm!

  • RAJH
  • Registratie: augustus 2001
  • Niet online
quote:
mark platvoet 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 ;)

Acties:
  • 0Henk 'm!

  • mark platvoet
  • Registratie: februari 2002
  • Laatst online: 19-08-2010

mark platvoet

Moutarde apres le diner

quote:
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?

Religion has no place in public schools the way facts have no place in organized religion


Acties:
  • 0Henk 'm!

  • RAJH
  • Registratie: augustus 2001
  • Niet online
Volgens wikipedia:
quote:
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.
quote:
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 :D

RAJH wijzigde deze reactie 09-07-2007 13:22 (41%)


Acties:
  • 0Henk 'm!

  • mark platvoet
  • Registratie: februari 2002
  • Laatst online: 19-08-2010

mark platvoet

Moutarde apres le diner

quote:
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 :)



quote:
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" ;)

mark platvoet wijzigde deze reactie 09-07-2007 13:13 (43%)

Religion has no place in public schools the way facts have no place in organized religion


Acties:
  • 0Henk 'm!

  • BikkelZ
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

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.

Remote iOS / Microsoft freelancer


Acties:
  • 0Henk 'm!

  • JKVA
  • Registratie: januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

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)

JKVA wijzigde deze reactie 09-07-2007 15:19 (24%)

Fat Pizza's pizza, they are big and they are cheezy


  • Icheb
  • Registratie: augustus 2001
  • Laatst online: 16-06 18:50
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 ?

sebsoft.nl


  • Optix
  • Registratie: maart 2005
  • Laatst online: 15-01 15:07
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
  • Registratie: mei 2000
  • Niet online

WouZz

Elvis is alive!

quote:
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.

On track


  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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 ;)

MBV wijzigde deze reactie 03-08-2007 16:06 (50%)


  • Icheb
  • Registratie: augustus 2001
  • Laatst online: 16-06 18:50
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.
quote:
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...

sebsoft.nl


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

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
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

quote:
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.
quote:
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 :/

Remote iOS / Microsoft freelancer


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

quote:
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
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
quote:
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.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

quote:
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
  • Registratie: april 2001
  • Laatst online: 06-05 14:03
quote:
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 :X

SchizoDuckie wijzigde deze reactie 09-08-2007 12:44 (8%)

Ik doe wel eens iets met fotos - DuckieTV - Mis niets meer van je favoriete TV-Series!


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

quote:
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 :X
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
  • Registratie: april 2001
  • Laatst online: 06-05 14:03
quote:
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 ;)

Ik doe wel eens iets met fotos - DuckieTV - Mis niets meer van je favoriete TV-Series!


  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
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.

Grijze Vos wijzigde deze reactie 09-08-2007 13:41 (8%)

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • BikkelZ
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

quote:
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.
quote:
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.

Remote iOS / Microsoft freelancer


  • kokx
  • Registratie: augustus 2006
  • Laatst online: 09-05 19:16

kokx

WIN

quote:
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.
quote:
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.

kokx wijzigde deze reactie 09-08-2007 14:05 (9%)


  • BastiaanN
  • Registratie: september 2003
  • Niet online

BastiaanN

[GoT]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?

BastiaanN


  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
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.

Grijze Vos wijzigde deze reactie 08-04-2009 11:23 (33%)

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • Cartman!
  • Registratie: april 2000
  • Niet online
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
  • Registratie: maart 2002
  • Niet online

Polichism

MOEHOE

(overleden)
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 :)

{02:31:10} (splinkie): ik hoor net van iemand dat ze nu met een fietsband moest naaien omdat ze geen condooms meer kon betalen || {02:34:44} (Asjemenou): beter met een lange tijd met goodyear dan een korte tijd met firestone en in de problemen komen


  • BikkelZ
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

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.

Remote iOS / Microsoft freelancer


  • raptorix
  • Registratie: februari 2000
  • Laatst online: 15-05 07:24
quote:
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
  • Registratie: september 2003
  • Niet online

BastiaanN

[GoT]BastiaanN

quote:
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.

BastiaanN


  • marco_balk
  • Registratie: april 2001
  • Laatst online: 27-04 17:47
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
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
quote:
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.
quote:
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.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • flashin
  • Registratie: augustus 2002
  • Laatst online: 31-08-2018
quote:
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 :D

  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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 ;)

MBV wijzigde deze reactie 09-04-2009 11:30 (35%)


  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
Ik -wou- dat ik overdreef. Hier:
code:
1
2
$:~/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.

Grijze Vos wijzigde deze reactie 09-04-2009 12:08 (32%)

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
Simpele manier:
find -iname "*.php" |xargs wc -l 

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

  • rutgerw
  • Registratie: juni 2004
  • Laatst online: 20:20
quote:
Grijze Vos schreef op donderdag 09 april 2009 @ 12:02:
Ik -wou- dat ik overdreef. Hier:
code:
1
2
$:~/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
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
quote:
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.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • rutgerw
  • Registratie: juni 2004
  • Laatst online: 20:20
Is je kritiek nu dat frameworks overkill zijn of dat typo3 overkill is?

  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 17-06 23:02
typo3 ;)

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

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
@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
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

quote:
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.

Remote iOS / Microsoft freelancer


  • MBV
  • Registratie: februari 2002
  • Laatst online: 18-06 16:17
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
  • Registratie: januari 2000
  • Laatst online: 18-06 10:55

BikkelZ

CMD+Z

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.

Remote iOS / Microsoft freelancer


  • WouZz
  • Registratie: mei 2000
  • Niet online

WouZz

Elvis is alive!

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.

On track


  • flijten
  • Registratie: september 2008
  • Laatst online: 22-10-2011
quote:
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....

  • DeProfessor
  • Registratie: september 2009
  • Laatst online: 07-05-2014
Hoe is de stand van zaken anno 2011 op dit terrein?

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

MueR wijzigde deze reactie 05-01-2011 15:41 (67%)


  • MueR
  • Registratie: januari 2004
  • Laatst online: 18-06 18:24

MueR

Moderator Devschuur®

is niet lief

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.

Anyone who gets in between me and my morning coffee should be insecure.

Pagina: 1

Dit topic is gesloten.



OnePlus 7 Pro (8GB intern) Microsoft Xbox One S All-Digital Edition LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 E3 2019

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True