Onderwerp: [ PHP framework ] basis voor te ontwikkelen applicaties

Ik heb mijzelf ook een beetje globaal zitten verdiepen in het Zend Framework, en het lijkt verdacht veel op CakePHP. Wel lijkt de opzet van CakePHP beter om snel te kunnen leren. Naar mijn mening logischere commando's / variablen. Een pro van ZF zou kunnen zijn dat het meer gebruik maakt van de PHP5 functies (OO) maar dat is maar net hoe je het bekijkt. Daarnaast merkte iemand op dat CakePHP slechts een verzameling classes zou zijn, maar als ik de zip van ZF open zie ik in de library/Zend map tevens een verzameling classes, en daarnaast, waarom zou dat niet goed kunnen zijn en wat is dan het alternatief.

Oorspronkelijk geplaatst door Freakingme

Ik zelf ken cakePHP dan weer (bijna) niet. Maar mij is verteld dat cakePHP evenals PEAR meer een verzameling van losse classes is.

Hmm uit mijn (toegegeven beperkte) ervaring installeer je niet een stel classes, maar pak je CakePHP uit in een publieke directory (dus niet zoals PEAR installeren in /usr/share). Vervolgens kun je commandline tools gebruiken om schermen te genereren (hoeft niet). Je gaat bouwen in de directory structuur die uit het CakePHP zip/tar.gz komt.

Het is dus geen verzameling losse classes.

Wat overigens wel interessant is, is dat hier de discussie zich concentreert op CakePHP en Zend Framework. Zijn dit de winnaars van de vraag die TS stelde?

Bezig met het Zend Framework. Leuke is dat er wekelijks wel een webcast is (gratis) waarbij er specifiek op een onderwerp wordt ingegaan.

Zelf je eigen framework bouwen kan, maar het zorgt voor veel extra werk, en dat werk is al enkele malen door anderen uitgevoerd; en de resultaten zijn vrij beschikbaar.

Zorg ervoor dat je een MVC framework gebruikt, en het gebruikt zoals het hoort (fat models, tiny controllers,... etc). CakePHP is een goede keuze, maar er zijn er beter (phptrax heb ik goei commentaar van gekregen). Wil je de moeder van CakePHP en PHPTrax gebruiken, dan dien je over te stappen naar Ruby, en het Rails-framework onderzoeken.

Eender welk framework je ook gebruikt, zorg ervoor dat je zelf zo weinig mogelijk code schrijft, en goed de mogelijkheden van het framework uitbuit.

Ik gebruik momenteel een zelf gemaakt MVC-Framework in php5. Niet super speciaal en ga me dus een beetje verdiepen in Zend Framework om te kijken of ik daar weet meer uit kan krijgen.

-----

Edit:
Ik zie het nut van ZendFramework niet. Het is alleen maar vervelend op te zetten IMO. CodeIgniter is veel simpeler te gebruiken en sneller te starten.

Uiteraard moet je helemaal zelf weten wat je gebruikt. Ik heb even gekeken naar CI, maar dit heeft imo duidelijk minder functionaliteit. Ook zijn andere classes uiterst beperkt m.i. waardoor je alsnog een heleboel zelf moet doen (vergeleken met ZF). Functies die ik veel gebruik zijn bijvoorbeeld AccessControlLists, queries constructen, authenticaten, etc. Ook heeft Zend een uiterst interessante pdf creater/reader. Dit alles is zie ik niet terug in CI.

Moet ik er wel bij zeggen dat ik er maar een paar minuten naar gekeken heb. ZF bestaat uit 150k regels code, om ZF en CI met elkaar te vergelijken in zo'n korte tijd is niet echt te doen

Momenteel ben ik druk bezig met de ontwikkeling van een eigen framework.
Geen commentaar, het is huis niet z'n huis-tuin/Newbie programmeering

Er is echt goed over nagedacht, momenteel nog in alpha face en een goede documentatie ontbreekt nog.
Ik wil nog wat dingen verbeteren. Momenteel is het heel stabiel.
Mocht je interesse hebben, https://svn.rollerscapes.net/rwf

En opmerkingen over dat wachtwoord in db.ini, in die database staat niets

Bedrijf waar ik voor werk begonnen we met een in-house PHP5 framework. Inmiddels heb ik een deel omgezet naar C++ om meer snelheid te krijgen. Ik heb toendertijd ook naar Zend Framework gekeken, maar helaas gebruikt die templatefiles, die wij ongeschikt vinden voor onze manier van werken (makkelijker voor een programmeur om in C++ objecten te denken en het framework de HTML laten hanteren en/of andere interface aan koppelen).

Je moet hier als bedrijf natuurlijk wel tijd/geld in willen steken, wat enkel voordeel geeft wanneer je meer complexere webapplicaties maakt dan een webshopje of blog. Zend Framework zit tussen in-house C++ framework en de honderden PHP frameworks in door de schaalbaarheid. Wil je snel een eenvoudige website maken dan zou ik meer in de template engines gaan kijken. Yahoo bijvoorbeeld gebruikt ook eigen C++ frameworks. Wanneer je een paar racks vol met webservers hebt dan wordt snelheid van het framework het allerbelangrijkst en valt eigenlijk alles in PHP en ASP af.

Als programmeur vind ik C++ leuker, PHP is geen programmeertaal

Interessant; gebruiken jullie nog wel Apache? En hoe worden de C++ binaries dan aangeroepen? CGI? FastCGI?

Hoe kwam je tot de conclusie dat PHP te traag was?

Oorspronkelijk geplaatst door Freakingme

Uiteraard moet je helemaal zelf weten wat je gebruikt. Ik heb even gekeken naar CI, maar dit heeft imo duidelijk minder functionaliteit. Ook zijn andere classes uiterst beperkt m.i. waardoor je alsnog een heleboel zelf moet doen (vergeleken met ZF). Functies die ik veel gebruik zijn bijvoorbeeld AccessControlLists, queries constructen, authenticaten, etc. Ook heeft Zend een uiterst interessante pdf creater/reader. Dit alles is zie ik niet terug in CI.

Moet ik er wel bij zeggen dat ik er maar een paar minuten naar gekeken heb. ZF bestaat uit 150k regels code, om ZF en CI met elkaar te vergelijken in zo'n korte tijd is niet echt te doen

Naar mijn weten ondersteund CI deze functies ook alleen dat PDF creater weet ik niet zeker. Ik zelf heb laatst een module gebouwd in een CMS dat was opgebouwd in CI. Ik moet zeggen dat het best lekker werkte en makkelijk te gebruiken was.

Het is ook wel begrijpelijk waarom CI nog niet van de functionaliteiten van PHP5 gebruikt maakt. Dit, omdat tijdens het moment van releasen PHP5 nog niet echt veel gebruikt werd. Ze willen in de toekomst wel steeds meer van PHP5 gebruik maken.

Oorspronkelijk geplaatst door bvankuik

Interessant; gebruiken jullie nog wel Apache? En hoe worden de C++ binaries dan aangeroepen? CGI? FastCGI?

Hoe kwam je tot de conclusie dat PHP te traag was?

Hangt van het project af; naargelang de wensen kun je het als (fast)CGI, PHP5 DLL extension, PHP5 core (mee compilen), of stand-alone applicatie m.b.v. sockets (IOCP) implementeren. Apache en IIS hebben al goed doordachte socket communicatie en afhandeling, dus persoonlijk ben ik een voorstander voor CGI en PHP extension. Dit laatste is tevens het makkelijkst uit te breiden, omdat je PHP er bij kunt "bouwen" (of laten doen, genoeg mensen die PHP kunnen, niet zo veel mensen die nog veel C doen).

Dit komt vooral omdat op informatica opleidingen leerlingen worden wijsgemaakt dat tegenwoordige computers toch snel zijn, en je daarom makkelijk een scripttaal of java etc kan nemen. Geheel onwaar voor servers (behalve als je een bodemloze buidel hebt, maar we heten niet allemaal Google). Kost altijd veel moeite om nieuwe mensen te overtuigen dat het toch echt wel belangrijk is om critisch om te gaan met code; zelfs met de keuze van een simpele for-loop of proberen duidelijk te maken dat templates sneller zijn dan OO-constructies met multiple extends. Tja, het eerste is veel moeilijker en het laatste staat in de schoolboeken (patterns, gang of four)

Als je meer wilt weten over PHP extensies in C schrijven ga dan naar Zend. Zend heeft veel informatie hierover en raad ook aan om over te gaan op C wanneer je highperformance zoekt. Sarah Bookman (weet niet zeker of de achternaam klopt) van Zend heeft hier een goed boek over geschreven (tutorials, voorbeelden, uitleg etc). Eerste hoofdstuk van haar kun je op zend.com vinden.

Sowieso een goede leerervaring: je komt er achter dat elke PHP5 variabele een C-struct (union) is met veel extra bagage. $a=3; kost je dus niet 4 bytes (een int32), maar 24 bytes. Ze doen echter wel slimme truukjes ($a is een smart pointer met een reference counter) waardoor geheugen veel gerecycled wordt. Dit kan ook een reden zijn om een PHP5 DLL te maken. Scheelt je erg veel geheugengebruik. Een ongetypeerde (script)taal (PHP, ASP) is fijn om mee te werken, maar al die voordelen hebben een prijs. Een C programma op 1 server kan ruim 32000 concurrent clients afhandelen. Een server met PHP niet.

Ik moet echter wel benadrukken dat dit natuurlijk geen goede oplossing is voor een klein project. Voordeel is natuurlijk wel dat dit voor meerdere/alle projecten meegaat en dat je niet bang hoeft te zijn dat je klant je PHP Framework sourcode steelt. Het zijn immers binairies. Je zult uit moeten rekenen of het goedkoper is om een server er "bij te prikken" of om een andere oplossing te verzinnen.

Edit: Ik hoop niet dat ik mijn verhaal al te technisch is voor dit forum, ik ben soms te enthousiast met typen

Integendeel...

Vind het erg interesant...
Ben zelf pas begonnen met C, dus een hele hoop te leren

Mijn eerste phpize module: StrIsInt
Maar zoals gezegd wil ik graag meer trucjes leren

je moet gewoon altijd goed de afweging maken. Enkel heel grote of specifieke projecten gaan compiled binaries nodig hebben, verder blijft het altijd goedkoper om je mensen een hogere taal te geven met meer structuur en mogelijkheden voor de opdracht, en het geld dat je daar uitspaart te besteden aan iets krachtigere machines. Personeel is en blijft de duurste factor voor ingrepen die langer dan een uur duren.

Dit is wel geen oproep om slechte en onefficiënte code te schrijven; goede en weldoordachte code zijn nog altijd onmisbaar, en zullen toelaten dat in latere stadia eenvoudig en gemakkelllijk geschaald kan worden, dat extras eenvoudig bijgemaakt kunnen worden, en dat bugs snel en eenvoudig opgespoord kunnen worden.

Niets is de heilige graal, elk werkt met de tools dat hij nodig heeft op een bepaald project. Een eenvoudige site in C/C++ gaan schrijven, via de CGI interface is ronduit debiel in de tijden van de mooie MVC frameworks. Een volledige real-time systeem gaan schrijven in PHP is ook gewoon ronduit debiel.

(en stop met die belachelijke uitspraak dat java traag zou zijn; er zijn benchmarks voor beide talen te vinden over het ganse internet).

Inderdaad, Java is zeker niet traag. Tomact met JSP en het ADF framework draaien heel mooi en daar heb je echt geen dikke servers voor nodig.

Inderdaad, het opstarten van de webserver (JBOSS in mijn geval) duurt even, een seconde of 20 a 30, maar als het draait, dan gaat het ook.

PHP begint voor websites met complexe structuren een steeds beter alternatief te worden, zeker het Zend framework draagt daar aan bij.

Ik ben nu een tijdje aan het ontwikkelen met dit framework en de leercurve is redelijk stijl, maar als je de basis eenmaal hebt, gaat het hard, heel hard.

Persoonlijk denk ik dat C/C++ zich niet al te goed lenen voor het draaien van webapplicaties, maar dat is mijn mening.

Als je zo nodig binnaries wilt gebruiken kan je dan niet beter PHP compileren naar byte-code? (Hoewel ik hier mijn bedenking over hebt omdat Perl gewoon de code omzet naar byte-code die niet meer leesbaar is maar nog steeds door de parser word gehaald).

Zend Framework is zoals ik al eerder zij, echt een knap staaltje techniek.
Voor mij was het echter niet aantrekkelijk genoeg, omdat veel dingen op een uiterst complexe manier gedaan worden, want als je 4/5 gelijkaardige projecten moet beheren met de zelfde functionaliteit (Klantpaneel, Backoffice, website, order systeem). Dan moet ik nog teveel copy-paste werk doen.
Dus heb ik iets ontwikkeld wat voor mij voldoet. Hierbij heb ik wel naar ZF, CI, CakePHP gekeken voor inspiratie.

Wat mij verbaast dat niemand Symphony vermeld, deze schijnt in de interprice wereld erg populair te zijn

Een nadeel van van CakePHP is dat je alles op HUN manier moet doen die volgens sommige niet echt prettig werkt.

CI:
+ Is erg licht, en bied niet veel functionaliteit, de code vind ik persoonlijk de een beetje bagger geschreven (Wie gebruikt er nu nog global )
+ Goede documentatie, hoewel die pagina mij gek maakten omdat hij sloom is en uiterst irritant is opgesteld... (Online versie)
- De meegeleverde HTML (view) is niet (x)HTML valid. Met inline CSS.

CakePHP:
- Was in een review van C't magazine bekritiseerd op het fijt van slechte documentatie.
- On-nodig complexe scripting, geen duidelijke structuur.
- Bij de download pagina moet je eerst aangeven of je wilt doneren... Een project kost geld oke, maar dit is wel erg opdringerig.