Standaard frameworks in PHP: wanneer wel en wanneer niet?

[iH8]

Modbreak:

Dit topic is afgesplitst van Gebruikers valideren in AD met PHP en begint daarom wat raar.

MueR schreef op zondag 21 november 2010 @ 13:57:
PHP heeft daar gewoon native ondersteuning voor? Waarom iedereen toch elke keer aankomt met dat logge ZF is me een raadsel.

Waarom iedereen toch altijd ZF log noemt als er maar één component aangehaald wordt is mij een raadsel. De TS komt zelf met "een script" aanzetten. Waarop hij terecht gewezen wordt op het feit dat hij dan beter ZF kan gebruiken. Nu wil hij in één keer "de functies" van PHP zelf gebruiken. FYI: ZF == PHP == Zend.

[ Voor 9% gewijzigd door NMe op 23-11-2010 12:33 ]

[Verwijderd]

MueR schreef op zondag 21 november 2010 @ 13:57:
PHP heeft daar gewoon native ondersteuning voor? Waarom iedereen toch elke keer aankomt met dat logge ZF is me een raadsel.

Toegegeven, is er in _elk_ framework een zekere overhead. En dus ook in Zend Framework. Echter is ZF nog steeds een zeer krachtig pakket en mits goed gebruikt ook zeer snel in gebruik. CakePHP is bijvoorbeeld véél trager, terwijl ZF juist meer kan. Wat betreft het ontwerp zit ZF zeer goed in elkaar en ik geloof dat enkel CodeIgniter sneller is dan ZF. En dan nog kan je als developer wat betreft optimalisatie genoeg doen met ZF om alsnog een blazend snelle webapplicatie op te zetten.
Het feit dat ZF voor heel veel dingetjes een component heeft, maakt het zo'n prettig pakket IMHO. Vandaar dat je het redelijk vaak langs ziet komen op ZF, denk ik.

[Freeaqingme]

MueR schreef op zondag 21 november 2010 @ 13:57:
PHP heeft daar gewoon native ondersteuning voor? Waarom iedereen toch elke keer aankomt met dat logge ZF is me een raadsel.

Hoor ik hier het Not invented here syndrome of een Please Reinvent The Wheel mentality? Een framework zoals ZF biedt gewoon functionaliteit die je ook wel zonder fw kan bereiken, maar het kost dan gewoon meer tijd/code/maintenance om dat te doen. En dat 't log is/ zou zijn, ja, het zal ongetwijfeld wat extra cpu cycles veroorzaken, maar liever wat extra cpu cycles dan developmenttijd (zolang je site niet zo groot is als google). Daarnaast heeft ZF niet voor niets Use at Will architectuur...

[NMe]

iH8 schreef op zondag 21 november 2010 @ 14:39:
[...]

FYI: ZF == PHP == Zend.

Dat het Zend framework toevallig gemaakt is door dezelfde organisatie die ook PHP gemaakt heeft wil nog niet zeggen dat het per definitie een goeie oplossing is. Naast het feit dat MueR terecht opmerkt dat het logge rotzooi is, is het ook nog eens niet zomaar overal aanwezig. Ook zit er nogal wat spul in dat gewoon compleet overengineered is voor het dagelijkse gebruik; dit topic is er een mooi voorbeeld van.

Inloggen op Active Directory middels LDAP is prima te doen met de standaard PHP-functies. Zo heb ik een jaar geleden nog ons intranet gebruik laten maken van de usergegevens die we ook voor alle andere dingen gebruiken op kantoor. Ik gebruik zelfs de gebruikersgroepen om rechten direct goed te zetten. Kan allemaal prima zonder ZF.

[Verwijderd]

NMe schreef op maandag 22 november 2010 @ 21:36:
[...]

Dat het Zend framework toevallig gemaakt is door dezelfde organisatie die ook PHP gemaakt heeft wil nog niet zeggen dat het per definitie een goeie oplossing is. Naast het feit dat MueR terecht opmerkt dat het logge rotzooi is, is het ook nog eens niet zomaar overal aanwezig. Ook zit er nogal wat spul in dat gewoon compleet overengineered is voor het dagelijkse gebruik; dit topic is er een mooi voorbeeld van.

Ik snap niet dat je zo kort door de bocht zegt dat ZF "logge rotzooi" is. Heb je überhaubt wel ervaring met ZF? Ik heb meerdere projecten lopen met ZF die allemaal zeer snel en betrouwbaar werken, zeker na wat optimalisaties (caching, dynamisch gebruik van plugins, enzovoort) hier en daar. Dat er in ZF componenten zitten die eigenlijk het wiel opnieuw willen uitvinden en de boel overcompliceren, is een verschijnsel wat zeker niet is voorbehouden aan ZF. Daarnaast heb je met ZF juist de mogelijkheid om deze componenten niet te gebruiken als je die niet nodig hebt.
Daarnaast ben ik van mening dat het uiteindelijk de programmeur is die de grootste invloed heeft op de werking van de applicatie, en niet noodzakelijkerwijs het gebruikte framework of zelfs de gebruikte programmeer- of scriptingtaal. Of je nu .NET, Zend Framework, Ruby on Rails of SharpCore gebruikt; als je niet goed en efficiënt programmeert, zal je applicatie langzaam en slecht werken.

Maargoed. Deze discussie leidt nergens toe behalve een welles-nietes discussie (wellicht zelfs een rare fanboy-discussie? ). Ik stel derhalve voor dat we die maar laten voor wat het is.
Maar iets genuanceerdere, beter beargumenteerde uitspraken mag écht wel vind ik, zeker als je kijkt naar de door mij zojuist beschreven punten.

[NMe]

Verwijderd schreef op maandag 22 november 2010 @ 22:45:
[...]

Maar iets genuanceerdere, beter beargumenteerde uitspraken mag écht wel vind ik, zeker als je kijkt naar de door mij zojuist beschreven punten.

Ik geloof dat ik nog best genuanceerd was, maar goed, als je het zo graag wil: een compleet framework gebruiken voor iets dat je in een handvol functiecalls net zo makkelijk zelf schrijft is niet bepaald een goeie zet.

[iH8]

Verwijderd schreef op zondag 21 november 2010 @ 14:50:

@iH8: Iedere schil die om de functies van PHP wordt gebouwd levert vertraging op, dat kun je niet ontkennen. Of dit nu significant is of niet, als het niet nodig is dan gebruik ik het liever niet.

Welke "schil"? Je bent zelf al tot de conclusie gekomen dat je of ergens een class moet pakken of zelf schrijven. Wat je ook doet, je zult altijd je applicatie om die functies heen moeten bouwen, of je het nu zelf doet of niet.

NMe schreef op maandag 22 november 2010 @ 21:36:

Dat het Zend framework toevallig gemaakt is door dezelfde organisatie die ook PHP gemaakt heeft wil nog niet zeggen dat het per definitie een goeie oplossing is.

In de meeste gevallen wel een betere oplossing als die van een third party.

NMe schreef op maandag 22 november 2010 @ 21:36:

Naast het feit dat MueR terecht opmerkt dat het logge rotzooi is, is het ook nog eens niet zomaar overal aanwezig.

Dat jullie dat een feit noemen zegt natuurlijk niets behalve dat jullie volgens mij nog nooit of te nimmer ZF gebruikt hebben. Dat het niet overal aanwezig is, tsja. Zijn Symphony of andere frameworks dat dan wel altijd?

NMe schreef op maandag 22 november 2010 @ 23:13:

een compleet framework gebruiken voor iets dat je in een handvol functiecalls net zo makkelijk zelf schrijft is niet bepaald een goeie zet.

NMe schreef op dinsdag 23 november 2010 @ 00:34:

ZF (of onderdelen daarvan) zullen best goed werken in bepaalde situaties maar in dit topic is het gewoon zware overkill. MueR en ik hekelen dat er zo snel gegrepen wordt naar een log framework in plaats van dat mensen gewoon een simpele eigen functie schrijven.

Het is nu al vaak gezegd maar het gaat er blijkbaar maar niet in. Ik heb niemand horen zeggen dat hij het gehele framework moet gebruiken. Hij kan zo enkel en alleen Zend_Auth includen. 't Is maar een class, een component, niets meer niets minder. Hij hoeft het hele framework niet eens te installeren. Iedereen snapt dat je verkeerd bezig bent als je voor het inloggen op een AD'tje een gehele MVC stack draait. Dat biedt hier ook niemand aan.

Verwijderd schreef op dinsdag 23 november 2010 @ 00:19:

Ik snap niet dat hier zo fel op wordt gereageerd (nota bene door moderators??) waarbij ZF wordt afgedaan als "logge rotzooi".

Dat begrijp ik inderdaad ook niet.

[NMe]

En ik begrijp die verdedigende toon niet wanneer ik zeg dat het niet performanter kan dan de standaardfuncties in PHP gebruiken. ZF zal die ook gebruiken, plus nog eens logica die eromheen zit. Leg mij eens voor eens en voor altijd uit waarom het Zend Framework of een losse module daarvan voor zoiets simpels als dit een betere oplossing zou zijn dan domweg de standaardfuncties gebruiken. Tot nu toe is alles wat ik in dit topic hoor wat gemiep dat het allemaal niet zo erg is als wij zeggen, maar intussen zie ik niet één steekhoudend argument waarom het wél gebruikt moet worden.

iH8 schreef op dinsdag 23 november 2010 @ 02:12:
[...]

In de meeste gevallen wel een betere oplossing als die van een third party.

Owja, want Zend is zo goed in het maken van ontwerpkeuzes. Daarom ontbreekt het in PHP ook nog steeds aan zoveel dingen en zijn zelfs simpele dingen als naming conventions compleet achterlijk opgezet (html_entity_decode vs. htmlentities bijvoorbeeld). Er is geen enkele reden om aan te nemen dat Zend betere keuzes maakt dan een derde partij.

Dat jullie dat een feit noemen zegt natuurlijk niets behalve dat jullie volgens mij nog nooit of te nimmer ZF gebruikt hebben.

Als ik ervoor kies om ZF vooral niet te gebruiken dan is dat een weloverwogen keuze. Toen ik bovenstaand stukje code schreef ben ik ook eerst bij het Zend Framework uitgekomen en heb ik besloten het niet te gebruiken omdat ik een specialistische klasse die precies deed wat ik nodig had (niets meer en niets minder) in net zoveel tijd in elkaar gedraaid zou hebben als wanneer ik Zend_Auth gebruikt had. Dan is de keuze verdomd makkelijk gemaakt: evenveel devtijd tegen betere prestaties en geen code in mijn framework die ik nooit nodig ga hebben.

Dat het niet overal aanwezig is, tsja. Zijn Symphony of andere frameworks dat dan wel altijd?

Nee, en ook die frameworks raad ik in dit topic niet aan.

[ Voor 13% gewijzigd door NMe op 23-11-2010 03:26 ]

[iH8]

NMe schreef op dinsdag 23 november 2010 @ 03:22:
En ik begrijp die verdedigende toon niet wanneer ik zeg dat het niet performanter kan dan de standaardfuncties in PHP gebruiken.

Zou dat misschien komen omdat jullie er beiden bovenop springen als het woord ZF valt maar het na laten om in te gaan op de TS en niets zeggen van die draak van een class waar hij zelf mee aankomt zetten? Als je zo pro-DIY bent dan kan je dat toch ook even gewoon melden zonder ZF te bashen met non-argumentatie.

NMe schreef op dinsdag 23 november 2010 @ 03:22:
Leg mij eens voor eens en voor altijd uit waarom het Zend Framework of een losse module daarvan voor zoiets simpels als dit een betere oplossing zou zijn dan domweg de standaardfuncties gebruiken. Tot nu toe is alles wat ik in dit topic hoor wat gemiep dat het allemaal niet zo erg is als wij zeggen, maar intussen zie ik niet één steekhoudend argument waarom het wél gebruikt moet worden.

Nou die zijn er wel degelijk genoemd om maar even wat te quoten:

Freeaqingme schreef op maandag 22 november 2010 @ 21:31:
Een framework zoals ZF biedt gewoon functionaliteit die je ook wel zonder fw kan bereiken, maar het kost dan gewoon meer tijd/code/maintenance om dat te doen.

NMe schreef op dinsdag 23 november 2010 @ 03:22:
Owja, want Zend is zo goed in het maken van ontwerpkeuzes. Daarom ontbreekt het in PHP ook nog steeds aan zoveel dingen en zijn zelfs simpele dingen als naming conventions compleet achterlijk opgezet (html_entity_decode vs. htmlentities bijvoorbeeld). Er is geen enkele reden om aan te nemen dat Zend betere keuzes maakt dan een derde partij.

Waarom raad je de TS niet meteen om C te gaan schrijven? Topic gaat over PHP, beetje flauw dit. Dat PHP niet voor vol aan gezien wordt weet ik. Daar ging het hier niet over. Waarom Zend de betere partij is voor een PHP Framework? Voor mij test-driven development, naadloze integratie met Zend Server en Studio, een community waar je U tegen zegt. Dan heb ik het nog niet eens over het framework zelf. Ik zie redenen genoeg.

NMe schreef op dinsdag 23 november 2010 @ 03:22:
Als ik ervoor kies om ZF vooral niet te gebruiken dan is dat een weloverwogen keuze. Toen ik bovenstaand stukje code schreef ben ik ook eerst bij het Zend Framework uitgekomen en heb ik besloten het niet te gebruiken omdat ik een specialistische klasse die precies deed wat ik nodig had (niets meer en niets minder) in net zoveel tijd in elkaar gedraaid zou hebben als wanneer ik Zend_Auth gebruikt had. Dan is de keuze verdomd makkelijk gemaakt: evenveel devtijd tegen betere prestaties en geen code in mijn framework die ik nooit nodig ga hebben.

Dat jij dat "even" doet wil niet zeggen dat dat geldt voor de TS of iemand anders. Tel jij dan ook je onderhoud en de tijd die je nodig hebt voor het schrijven van unittests etc? Ieder z'n eigen framework is allemaal leuk en aardig maar er zijn ook nog mensen die vooruit willen. Been there, done that, ik hoef geen t-shirt.

Write less, do more.

[Verwijderd]

Kijk bijvoorbeeld hier eens naar:
http://avnetlabs.com/php/php-framework-comparison-benchmarks

Je kunt natuurlijk ook zelf iets gaan proberen met je eigen applicatie, maar dat zal misschien veel tijd kosten.

Een framework gebruiken betekent meestal een hevige impact op de performance. Daar staat tegenover dat als je een framework eenmaal kent, je er vaak sneller mee kunt ontwikkelen omdat je minder bugs maakt.

Zie bijvoorbeeld dat CodeIgniter ongeveer 3 keer zo snel is als Zend Framework. Maar rauwe PHP is weer een factor 15-20 keer sneller! Misschien dat je nu inziet waarom een framework "log" wordt genoemd. Ze zijn log. Maar je kunt er ontwikkeltijd mee besparen.

Dat neemt niet weg dat je voor een drukke website toch misschien beter dat framework niet kunt gebruiken, of in elk geval anders. Met CodeIgniter kun je misschien besparen op een virtuele of fysieke server. Met rauwe PHP nog veel meer. Of dat het waard is zul je per geval moeten bekijken.

[Verwijderd]

Verwijderd schreef op dinsdag 23 november 2010 @ 08:25:
Kijk bijvoorbeeld hier eens naar:
http://avnetlabs.com/php/php-framework-comparison-benchmarks

Je kunt natuurlijk ook zelf iets gaan proberen met je eigen applicatie, maar dat zal misschien veel tijd kosten.

Een framework gebruiken betekent meestal een hevige impact op de performance. Daar staat tegenover dat als je een framework eenmaal kent, je er vaak sneller mee kunt ontwikkelen omdat je minder bugs maakt.

Zie bijvoorbeeld dat CodeIgniter ongeveer 3 keer zo snel is als Zend Framework. Maar rauwe PHP is weer een factor 15-20 keer sneller! Misschien dat je nu inziet waarom een framework "log" wordt genoemd. Ze zijn log. Maar je kunt er ontwikkeltijd mee besparen.

Dat neemt niet weg dat je voor een drukke website toch misschien beter dat framework niet kunt gebruiken, of in elk geval anders. Met CodeIgniter kun je misschien besparen op een virtuele of fysieke server. Met rauwe PHP nog veel meer. Of dat het waard is zul je per geval moeten bekijken.

Dat heb ik gelezen en inderdaad: raw PHP is (uiteraard) veel sneller omdat daar geen logische lagen meer omheen zitten. Maargoed, als je écht het snelste wilt kan je net zo goed procedureel gaan programmeren in native PHP.

Zoals NMe terecht aangeeft heeft PHP wat onhandige puntjes, en dat is ook zo. Zeker op object-georiënteerd gebied heeft PHP zeker quirks waarmee je moet om leren gaan. PHP is ook zeer makkelijk te leren, snel in gebruik en is nog volop aan het evolueren. De daadwerkelijke keus om PHP te gaan gebruiken hangt van de programmeur af. Diezelfde afweging maak je bij _elke_ stap in de ontwikkeling en dus ook in de keuze van het al dan niet gebruiken van een (eigen) framework.

Iedereen heeft z'n eigen succesformule, en het mooie van een thread als deze is dat je ook van elkaar kan leren en tot nieuwe inzichten kan komen. Dat is toch precies het doel van een forum, als je er zo over denkt?

[iH8]

Verwijderd schreef op dinsdag 23 november 2010 @ 08:25:
Kijk bijvoorbeeld hier eens naar:
http://avnetlabs.com/php/php-framework-comparison-benchmarks

Je kunt natuurlijk ook zelf iets gaan proberen met je eigen applicatie, maar dat zal misschien veel tijd kosten.

Een framework gebruiken betekent meestal een hevige impact op de performance. Daar staat tegenover dat als je een framework eenmaal kent, je er vaak sneller mee kunt ontwikkelen omdat je minder bugs maakt.

Zie bijvoorbeeld dat CodeIgniter ongeveer 3 keer zo snel is als Zend Framework. Maar rauwe PHP is weer een factor 15-20 keer sneller! Misschien dat je nu inziet waarom een framework "log" wordt genoemd. Ze zijn log. Maar je kunt er ontwikkeltijd mee besparen.

Dat neemt niet weg dat je voor een drukke website toch misschien beter dat framework niet kunt gebruiken, of in elk geval anders. Met CodeIgniter kun je misschien besparen op een virtuele of fysieke server. Met rauwe PHP nog veel meer. Of dat het waard is zul je per geval moeten bekijken.

Erhmz. Die benchmark is uit 2008?!?! Zend Framework is inmiddels al 27(!) versies verder. Buiten dat zou ik dat gebenchmark in de meeste gevallen maar met een goede korrel zout nemen. Lees anders even dit:

http://blog.astrumfutura....g-but-ultimately-useless/

Dan raad ik ook nog niets eens aan om met ZF te gaan werken. Ik raad aan Zend_Auth en bijbehorende LDAP adapter te gebruiken. Jullie kunnen mij over en over blijven vertellen dat het gebruik van een volledig framework trager is maar dat raad ik toch niet aan?

PHP:

<?php

require_once "Zend/Auth.php";
require_once "Zend/Auth/Adapter/Ldap.php";

$options = array(
    'server1' => array(
        'host' => 'dc1.w.net',
        'useStartTls' => 1,
        'accountDomainName' => 'w.net',
        'accountDomainNameShort' => 'W',
        'accountCanonicalForm' => 3,
        'baseDn' => 'CN=Users,DC=w,DC=net'
    )
);

$auth = Zend_Auth::getInstance();
$adapter = new Zend_Auth_Adapter_Ldap($options, 'myUserName', 'myPassword'); 
$result = $auth->authenticate($adapter);

Als een klant naar me toekomt en opdraagt: wij moeten via PHP inloggen op een AD, dan sta ik letterlijk vijf minuten later buiten en laat hem achter met een betrouwbare ondersteunde oplossing. Daar ga ik zoals NMe zou doen, echt niet voor zitten. Dat jullie durven claimen dat een zelf geschreven oplossing beter en sneller is dat vind ik een gewaagde uitspraak zeker als je die baseert op benchmarks van en/of ervaringen met de volledige MVC. Daar hebben we het hier niet over. Ik heb het over Zend_Auth en Zend_Auth_Adapter_Ldap.

[NMe]

Nogmaals: noem mij één reden waarom jouw oplossing beter is dan de mijne. Devtijd is geen excuus; ik heb het stukje code dat ik hierboven gepost heb net zo goed binnen een paar minuten geschreven. En ik had destijds geen ervaring met LDAP.

Je bent nu al dit hele topic lang het ZF-evangelie aan het verkondigen omdat het allemaal perfect doet wat je wil. Dat doet mijn code ook, en nog sneller ook; Zend_Auth_Adapter_Ldap gebruikt namelijk exact dezelfde functies die ik ook gebruik, alleen zit er bij ZF nog bloat omheen die voor anderen vast heel handig is, maar die je voor domweg inloggen op AD niet nodig hebt.

iH8 schreef op dinsdag 23 november 2010 @ 12:06:
[...]


Erhmz. Die benchmark is uit 2008?!?! Zend Framework is inmiddels al 27(!) versies verder.

Dus? Dat zijn andere frameworks en PHP zelf ook. Daarnaast zal een framework, ongeacht de versie, nooit de snelheid die de taal native biedt overstijgen.

Buiten dat zou ik dat gebenchmark in de meeste gevallen maar met een goede korrel zout nemen. Lees anders even dit:

http://blog.astrumfutura....g-but-ultimately-useless/

Naast het feit dat dat geschreven is door een ZF-evangelist is de enige manier waarop hij extra snelheid boekt juist door het niet gebruiken van bepaalde delen van ZF, waar de andere frameworks wel gewoon hun eigen functionaliteit gebruiken. Daarnaast: hij vergelijkt nergens met native PHP.

[Verwijderd]

iH8, je begrijpt mijn punt niet. Ik probeer te vertellen dat het altijd kiezen voor één bepaalde oplossing dom is. Het hangt af van de requirements, van de schaal en van nog veel meer.

En zoiets simpels als dit... om daar nou een "dependency" voor toe te voegen?

Je gedraagt je overigens als een fanboy. Probeer eens als niet-ZF-gebruiker naar de argumenten te kijken en je zult zien dat er behoorlijk wat waarheid in zit.

[iH8]

NMe schreef op dinsdag 23 november 2010 @ 12:19:
Nogmaals: noem mij één reden waarom jouw oplossing beter is dan de mijne. Devtijd is geen excuus; ik heb het stukje code dat ik hierboven gepost heb net zo goed binnen een paar minuten geschreven. En ik had destijds geen ervaring met LDAP.

Nogmaals, dat jij zoiets binnen een paar minuten schrijft, ok. Voor anderen is dat misschien niet zo. Die zullen beter moeten letten op de pitfalls die authenticatie met zich mee brengt en dan voel je jezelf een stuk veiliger wetende dat er voor je op de flaws gelet wordt.

NMe schreef op dinsdag 23 november 2010 @ 12:19:Zend_Auth_Adapter_Ldap gebruikt namelijk exact dezelfde functies die ik ook gebruik, alleen zit er bij ZF nog bloat omheen die voor anderen vast heel handig is, maar die je voor domweg inloggen op AD niet nodig hebt.

Wat jij bloated noemt dat noem ik mooi meegenomen. Vertel me dan eens wat er zo bloated is aan dat component? Aangezien ik je nogsteeds niet gehoord heb over de class die de TS aandraagt, ben ik erg benieuwd.

Gebruikers valideren in AD met PHP

NMe schreef op dinsdag 23 november 2010 @ 12:19:
Dus? Dat zijn andere frameworks en PHP zelf ook. Daarnaast zal een framework, ongeacht de versie, nooit de snelheid die de taal native biedt overstijgen.

Daar mee wilde ik alleen maar zeggen dat de door Cheatah aangedragen benchmark niet meer relevant is. Natuurlijk is een geoptimaliseerde right-to-the-point oplossing sneller. Als developmenttijd toch geen factor is dan kun je natuurlijk ook zelf opcode schrijven. Zal nog wel sneller zijn als je weet waar je meebezig bent. Of je slim bezig bent is een tweede.

NMe schreef op dinsdag 23 november 2010 @ 12:19:
Naast het feit dat dat geschreven is door een ZF-evangelist is de enige manier waarop hij extra snelheid boekt juist door het niet gebruiken van bepaalde delen van ZF, waar de andere frameworks wel gewoon hun eigen functionaliteit gebruiken.

Als je het artikel goed leest dan zie je dat het geen pro-ZF benchmark is. Het toont alleen aan dat er geen goede manier is om frameworks eerlijk te benchmarken. Je kunt zelf uitmaken hoe je je framework gebruikt. Dat zal voor een amateur betekenen dat hij inderdaad eerst een paar rondjes in z'n nieuwe ferarri doet met traction en launchcontrol enabled.

NMe schreef op dinsdag 23 november 2010 @ 12:19:
Daarnaast: hij vergelijkt nergens met native PHP.

Is dat niet totaal onmogelijk? Wat je ook doet je zult logica om die native functies heen moeten schrijven wil je er mee werken, dat kun je benchmarken. Ik volg je redenatie niet.

Verwijderd schreef op dinsdag 23 november 2010 @ 12:30:
iH8, je begrijpt mijn punt niet. Ik probeer te vertellen dat het altijd kiezen voor één bepaalde oplossing dom is. Het hangt af van de requirements, van de schaal en van nog veel meer.

En zoiets simpels als dit... om daar nou een "dependency" voor toe te voegen?

De stelling was, ik heb deze class gevonden, is dat wat, of moet ik zelf iets schrijven, of iets anders bestaands gebruiken. Nu kunnen jullie er allemaal hard over vallen dat er dan iemand een class uit ZF aanbiedt, dat gaat nergens over natuurlijk. Je kunt ook gewoon de TS meteen rond zijn oren slaan met zoals Freeaqingme het noemt " Not invented here syndrome of een Please Reinvent The Wheel mentality"

Verwijderd schreef op dinsdag 23 november 2010 @ 12:30:
Je gedraagt je overigens als een fanboy. Probeer eens als niet-ZF-gebruiker naar de argumenten te kijken en je zult zien dat er behoorlijk wat waarheid in zit.

Zoals hier boven gesteld wordt er alleen gereageerd op het opperen van ZF. Dat dat dan gepaard moet met het voor waar verklaren van non-argumenten die niet gestaaft kunnen, tsja. Ik noem dat niet constructief reageren, ik noem dat trollen. Dan haal je het beste uit een ZF gebruiker boven inderdaad. Sommigen (zoals gezegd, jammer genoeg moderators) trekken het hier zwaar offtopic door te beginnen over het gebruik van frameworks, overhead en dergelijke. En dat dan alleen omdat het over ZF gaat. Dat gedrocht van een class in de TS wordt voor het gemak over het hoofd gezien. Beetje jammer allemaal, maar zo leer je wel de mensen kennen.

[NMe]

iH8 schreef op dinsdag 23 november 2010 @ 14:01:
[...]

Nogmaals, dat jij zoiets binnen een paar minuten schrijft, ok. Voor anderen is dat misschien niet zo. Die zullen beter moeten letten op de pitfalls die authenticatie met zich mee brengt en dan voel je jezelf een stuk veiliger wetende dat er voor je op de flaws gelet wordt.

Mja, tot je erop rekent dat zo'n framework dat je zelf niet geschreven hebt inderdaad rekening houdt met alle pitfalls en je een keer ongenadig hard op je gat gaat omdat ze dat dus niet voor elke pitfall doen.

Daarnaast ben ik helemaal niet zo'n bijzonder goeie developer die alles weet. Mijn expertise ligt weliswaar bij PHP, maar ik heb pas twee jaar echt professionele ervaring. Ten tijde van het schrijven van mijn LDAP-klasse was ik net een half jaartje aan de slag als fulltime PHP-ontwikkelaar. Als ik er destijds al in een paar minuten een oplossing voor schrijf, dan kan een ander dat ook.

Wat jij bloated noemt dat noem ik mooi meegenomen. Vertel me dan eens wat er zo bloated is aan dat component? Aangezien ik je nogsteeds niet gehoord heb over de class die de TS aandraagt, ben ik erg benieuwd.

Gebruikers valideren in AD met PHP

Wat heb ik te maken met een random class die iemand van het internet plukt? Die heb ik niet geschreven noch raad ik hem aan. Dat heeft niets te maken met het feit dat een algemene class in een random framework (of dat nu ZF is of niet) geschreven is om vooral maar zoveel mogelijk features te faciliteren. Als je die features niet gebruikt, dan heet dat bloat.

Daar mee wilde ik alleen maar zeggen dat de door Cheatah aangedragen benchmark niet meer relevant is. Natuurlijk is een geoptimaliseerde right-to-the-point oplossing sneller. Als developmenttijd toch geen factor is dan kun je natuurlijk ook zelf opcode schrijven. Zal nog wel sneller zijn als je weet waar je meebezig bent. Of je slim bezig bent is een tweede.

Doe eens niet zo overchargeren. Mijn drie functiecalls zijn niet meer of minder codewerk dan jouw Zend_Auth. Bovendien zijn ze geschreven in dezelfde programmeertaal als ZF, dus je complete vergelijking gaat mank. Daarnaast zei ik dat devcode geen issue was omdat het even lang duurt om 3 native functies aan te roepen als wanneer je een aantal methods van een random framework gebruikt. Ik heb nooit gezegd dat devtijd niet uitmaakt, ik heb gezegd dat het in het hier besproken voorbeeld compleet irrelevant is als argument.

Als je het artikel goed leest dan zie je dat het geen pro-ZF benchmark is. Het toont alleen aan dat er geen goede manier is om frameworks eerlijk te benchmarken. Je kunt zelf uitmaken hoe je je framework gebruikt. Dat zal voor een amateur betekenen dat hij inderdaad eerst een paar rondjes in z'n nieuwe ferarri doet met traction en launchcontrol enabled.

Er is wel een goeie manier om frameworks te benchmarken, namelijk dezelfde dingen proberen te doen, beiden met default options. Dat is namelijk de standaard toolbox die je krijgt van je framework, dát is een eerlijke benchmark. Een framework op zo'n manier benchmarken dat je weet dat hij een oneerlijk voordeel krijgt (door stukjes code te skippen en vervolgens die vergelijkbare optimalisatieslag niet in de andere frameworks te maken) is gewoon kinderachtig. Die blogpost is dus redelijk kansloos en IMO een stuk oneerlijker dan de benchmark die Cheatah aanhaalt.

Is dat niet totaal onmogelijk? Wat je ook doet je zult logica om die native functies heen moeten schrijven wil je er mee werken, dat kun je benchmarken. Ik volg je redenatie niet.

Je hoeft helemaal geen logica om je native functies heen te schrijven als je dat wil. Iemand die graag mysql_query aanroept in zijn code in plaats van een databaseclass te schrijven die nog wat meer fancy spul doet mag dat best, en dat outperformt die custom class ook gegarandeerd. Het hangt van de situatie af of het gebruiken van native functionaliteit al dan niet beter is dan het gebruiken van een framework. ZF is niet zomaar per definitie de juiste oplossing net zoals native PHP gebruiken niet per definitie altijd de juiste oplossing is.

De stelling was, ik heb deze class gevonden, is dat wat, of moet ik zelf iets schrijven, of iets anders bestaands gebruiken. Nu kunnen jullie er allemaal hard over vallen dat er dan iemand een class uit ZF aanbiedt, dat gaat nergens over natuurlijk. Je kunt ook gewoon de TS meteen rond zijn oren slaan met zoals Freeaqingme het noemt " Not invented here syndrome of een Please Reinvent The Wheel mentality"

Wij vielen er hard over dat een class uit een framework wordt aangeboden die niks extra's biedt boven het veel beter performende setje native functies dat in PHP zit. Daarna worden de valide argumenten genoemd dat zo'n ZF-module bloated is, trager werkt en een dependency vereist, terwijl het in dit geval geen devtijdverkorting oplevert. Wat is dan nog je argument om het wel te gebruiken? Je zit ons steeds te manen tot het geven van argumenten waarom wij vinden dat het niet gebruikt moet worden in deze situatie, maar jij geeft nergens aan waarom het in deze specifieke situatie nou zo'n geweldig goed idee is.

Zoals hier boven gesteld wordt er alleen gereageerd op het opperen van ZF. Dat dat dan gepaard moet met het voor waar verklaren van non-argumenten die niet gestaaft kunnen, tsja. Ik noem dat niet constructief reageren, ik noem dat trollen. Dan haal je het beste uit een ZF gebruiker boven inderdaad. Sommigen (zoals gezegd, jammer genoeg moderators) trekken het hier zwaar offtopic door te beginnen over het gebruik van frameworks, overhead en dergelijke. En dat dan alleen omdat het over ZF gaat. Dat gedrocht van een class in de TS wordt voor het gemak over het hoofd gezien. Beetje jammer allemaal, maar zo leer je wel de mensen kennen.

Mja, leuk, die Calimero-houding, zo win je eens discussie. Sowieso heb ik de discussie afgesplitst dus guess what: we zijn niet meer offtopic. We gebruiken valide argumenten, jij noemt er eentje, namelijk devtijd. Die kan ik uit praktijkervaring ontkrachten. Wat blijft er nog over van je argumentatie?

En nogmaals: niemand heeft dat "gedrocht van een class" in de topicstart aangeraden en niemand heeft gezegd dat het een goede oplossing was. Sterker nog, niemand heeft er iets van gezegd omdat de topicstarter het zelf al afgeschreven heeft. Wat wil je dat ik er verder nog over zeg?

[ Voor 5% gewijzigd door NMe op 23-11-2010 14:32 ]

[kwaakvaak_v2]

Er lijkt alleen 1 misvatting te bestaan, en dat is dat zend het zend framework ontwikkeld, en dat is in die definitie niet helemaal correct. Zend overziet de ontwikkeling van het framework, maar de ontwikkeling zelf is wel een puur community ding, met behoorlijk wat verschillende contributors die niet bij/voor zend werken.

Zend is meer een sponsor voor de infrastructuur, en overkoepelend orgaan en ze hebben een aantal mensen in dienst, of in dienst genomen om het framework te ontwikkelen.

Maar het is niet zo dat zend framework dingen kan/mag doen die andere frameworks niet kunnen omdat toevallig de naam zend er in voor komt.

Wat niet weg neemt dat ik idd vind dat in ZF1 dingen soms nogal log en overbodig complex zijn gedaan, maar gelukkig hebben ze dat zelf ook ingezien en voor ZF2 wel een aantal structurele wijzigingen door gevoerd.

[Freeaqingme]

NMe schreef op dinsdag 23 november 2010 @ 14:29:
[...]
Er is wel een goeie manier om frameworks te benchmarken, namelijk dezelfde dingen proberen te doen, beiden met default options. Dat is namelijk de standaard toolbox die je krijgt van je framework, dát is een eerlijke benchmark.

Ja, dat is eerlijk, helemaal mee eens. Wat niet eerlijk is, is de conclusie die daar veelvuldig aan verbonden wordt (namelijk dat je het beste het snelste fw kan gebruiken). Dit is enerzijds omdat je een framework primair gebruikt omdat het de ontwikkelingstijd verkleint. Immers, als het iedereen enkel om de laadtijden ging gebruikte iedereen wel ASM (en php mag dan niet perfect zijn, ik verkies vrijwel alles - inclusief php - boven ASM). Anderzijds is dit omdat een realworld applicatie altijd meer functionaliteit biedt dan de apps die gebruikt worden in benchmarks.

Zonder die hele benchmark pagina te hebben doorgenomen, als je 9 requests per second haalt doe je iets fout, welk framework je ook gebruikt. Daarnaast is het natuurlijk zo dat als een framework je heel veel opties geeft, en handreikingen doet/geeft om 't uit te breden en overal je eigen componenten te kunnen gebruiken (use at will) is 't vreemd om die andere benchmark daar op af te rekenen.

Dat gezegd hebbende, uiteraard ga je in 't geval van een scripjte van een paar regels code niet een framework component gebruiken dat 100 keer groter is dan 't scriptje zijn zou. Ik ken ldap/ad (waar het originele topic mee begon) niet echt, maar ik ben in ieder geval geen fan van Zend_Auth in grotere applicaties omdat 't daarin vrijwel nooit zal voldoen (ja, ik ben Community Review Team Member, maar dat zegt niet dat ik fan ben van alle 600000 regeltjes code).

Er lijkt alleen 1 misvatting te bestaan, en dat is dat zend het zend framework ontwikkeld, en dat is in die definitie niet helemaal correct. Zend overziet de ontwikkeling van het framework, maar de ontwikkeling zelf is wel een puur community ding, met behoorlijk wat verschillende contributors die niet bij/voor zend werken.

Dat wil ik graag even bevestigen Zend heeft momenteel 3 fulltime employees in dienst om aan ZF te bouwen, en het gebeurt soms (zelden) dat er op deze mensen politieke druk voor wat betreft ZF functionaliteit wordt uitgeoefend. Echter, hier wordt niet aan toegegeven. Daarnaast klopt die lijst met contributors niet helemaal meer. Er zijn ongeveer 50 (schat ik) actieve contributors, waarvan er nog maar 10 in die lijst voorkomen. Komt vooral omdat die lijst uit (ongeveer) 2007 stamt, en er sindsdien nog maar 2 foto's aan zijn toegevoegd.

offtopic:
Ik ben al een aantal jaar betrokken bij ZF, enige tijd contributor en sinds kort ook Community Review Team Member. Desalniettemin heb ik geprobeerd met inhoudelijke argumenten te komen. Bij deze dan ook het verzoek om daar inhoudelijk op te reageren, en er niet bij voorbaat van uit te gaan dat ik biased ben/zou zijn.

[NMe]

Freeaqingme schreef op dinsdag 23 november 2010 @ 17:01:
[...]

Ik ben al een aantal jaar betrokken bij ZF, enige tijd contributor en sinds kort ook Community Review Team Member. Desalniettemin heb ik geprobeerd met inhoudelijke argumenten te komen. Bij deze dan ook het verzoek om daar inhoudelijk op te reageren, en er niet bij voorbaat van uit te gaan dat ik biased ben/zou zijn.

Je zegt feitelijk precies wat ik wil zeggen: blind kiezen voor een framework of juist blind kiezen om zo'n framework juist niet te gebruiken is beiden niet goed. Het cliché "use the right tool for the right job" is hier van toepassing.

[iH8]

NMe schreef op dinsdag 23 november 2010 @ 14:29:

Mja, tot je erop rekent dat zo'n framework dat je zelf niet geschreven hebt inderdaad rekening houdt met alle pitfalls en je een keer ongenadig hard op je gat gaat omdat ze dat dus niet voor elke pitfall doen.

Daarnaast ben ik helemaal niet zo'n bijzonder goeie developer die alles weet. Mijn expertise ligt weliswaar bij PHP, maar ik heb pas twee jaar echt professionele ervaring. Ten tijde van het schrijven van mijn LDAP-klasse was ik net een half jaartje aan de slag als fulltime PHP-ontwikkelaar. Als ik er destijds al in een paar minuten een oplossing voor schrijf, dan kan een ander dat ook.

En jij wil zeggen dat wat jij in vijf minuten schrijft geen fouten kan bevatten of onderhoud behoeft? Het zou toch ook gewoon kunnen dat iemand daar geen tijd/zin whatever in heeft, maar zich liever met de big-picture bezighoudt? Ik volg totaal niet waarom jou stramien voor iedereen zou moeten gelden. Ik vind het wel fijn dat er binnen Zend_Auth rekening gehouden wordt met nieuwe zaken zoals remote timing attacks en dergelijke. Als je dat soort dingen zelf bij wil houden fine, maar dan moet je er wel tijd voor en zin in hebben.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Wat heb ik te maken met een random class die iemand van het internet plukt? Die heb ik niet geschreven noch raad ik hem aan. Dat heeft niets te maken met het feit dat een algemene class in een random framework (of dat nu ZF is of niet) geschreven is om vooral maar zoveel mogelijk features te faciliteren. Als je die features niet gebruikt, dan heet dat bloat.

Dat zeg je nu. Eerst was ZF is traag en bloated waarop overduidelijk gewezen wordt op benchmarks van OOP/MVC framework stacks, iets wat hier compleet niet van toepassing is. Dat Zend_Auth in jou ogen bloated is, dat kan. Traag, neej, minder snel, misschien. Hardware is nog altijd cheaper dan een developer zeggen ze hier dan.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Er is wel een goeie manier om frameworks te benchmarken, namelijk dezelfde dingen proberen te doen, beiden met default options. Dat is namelijk de standaard toolbox die je krijgt van je framework, dát is een eerlijke benchmark. Een framework op zo'n manier benchmarken dat je weet dat hij een oneerlijk voordeel krijgt (door stukjes code te skippen en vervolgens die vergelijkbare optimalisatieslag niet in de andere frameworks te maken) is gewoon kinderachtig. Die blogpost is dus redelijk kansloos en IMO een stuk oneerlijker dan de benchmark die Cheatah aanhaalt.

Ik haal toch iets heel anders uit die blogpost:

It’s time to ask the question on everybody’s minds: what does it all mean? Give up. There is no meaning in benchmarks. They are designed to compare the relative performance of frameworks with different goals, design philosophies, development practices, and features. Might as well flip a coin, roll some dice

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Doe eens niet zo overchargeren. Mijn drie functiecalls zijn niet meer of minder codewerk dan jouw Zend_Auth. Bovendien zijn ze geschreven in dezelfde programmeertaal als ZF, dus je complete vergelijking gaat mank. Daarnaast zei ik dat devcode geen issue was omdat het even lang duurt om 3 native functies aan te roepen als wanneer je een aantal methods van een random framework gebruikt. Ik heb nooit gezegd dat devtijd niet uitmaakt, ik heb gezegd dat het in het hier besproken voorbeeld compleet irrelevant is als argument.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Je hoeft helemaal geen logica om je native functies heen te schrijven als je dat wil. Iemand die graag mysql_query aanroept in zijn code in plaats van een databaseclass te schrijven die nog wat meer fancy spul doet mag dat best, en dat outperformt die custom class ook gegarandeerd. Het hangt van de situatie af of het gebruiken van native functionaliteit al dan niet beter is dan het gebruiken van een framework. ZF is niet zomaar per definitie de juiste oplossing net zoals native PHP gebruiken niet per definitie altijd de juiste oplossing is.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Wij vielen er hard over dat een class uit een framework wordt aangeboden die niks extra's biedt boven het veel beter performende setje native functies dat in PHP zit. Daarna worden de valide argumenten genoemd dat zo'n ZF-module bloated is, trager werkt en een dependency vereist, terwijl het in dit geval geen devtijdverkorting oplevert. Wat is dan nog je argument om het wel te gebruiken? Je zit ons steeds te manen tot het geven van argumenten waarom wij vinden dat het niet gebruikt moet worden in deze situatie, maar jij geeft nergens aan waarom het in deze specifieke situatie nou zo'n geweldig goed idee is.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
We gebruiken valide argumenten, jij noemt er eentje, namelijk devtijd. Die kan ik uit praktijkervaring ontkrachten. Wat blijft er nog over van je argumentatie?

Je moet mij niet voor mijn voeten gooien dat ik de TS Zend_Auth aangeraden heb, ik zie ook niet in waarom ik dat dan zou moeten verdedigen. Ik kom alleen maar vragen waarom jullie daar (en wel vaker) het gehele framework afkraken met argumenten over traag, log en bloated terwijl er helemaal niet gepraat wordt over het gebruik van ZF. Iemand biedt Zend_Auth aan en jullie vallen over elkaar heen om ZF de grond in te boren om je naderhand zacht uit de hoek te komen met: "Ja maar frameworks, classes, whatever eigenlijk allemaal niet nodig, zelf doen"

NMe schreef op dinsdag 23 november 2010 @ 14:29:
Mja, leuk, die Calimero-houding, zo win je eens discussie. Sowieso heb ik de discussie afgesplitst dus guess what: we zijn niet meer offtopic.

Jij hebt de discussie afgesplitst ja, dat had ik meteen al door. Een non-biased geinteresseerd iemand had er van gemaakt [PHP] Frameworks, wanneer wel, wanneer niet en welke?. Dit topic siert je helemaal niet. Call me Calimero, call me what you will.

NMe schreef op dinsdag 23 november 2010 @ 14:29:
En nogmaals: niemand heeft dat "gedrocht van een class" in de topicstart aangeraden en niemand heeft gezegd dat het een goede oplossing was.

Jullie hebben het ook niet afgeraden, ZF wel en dat bedoel ik.

[ Voor 9% gewijzigd door iH8 op 23-11-2010 17:14 . Reden: c/p foutje ]

[NMe]

iH8 schreef op dinsdag 23 november 2010 @ 17:12:
[...]

En jij wil zeggen dat wat jij in vijf minuten schrijft geen fouten kan bevatten of onderhoud behoeft? Het zou toch ook gewoon kunnen dat iemand daar geen tijd/zin whatever in heeft, maar zich liever met de big-picture bezighoudt? Ik volg totaal niet waarom jou stramien voor iedereen zou moeten gelden. Ik vind het wel fijn dat er binnen Zend_Auth rekening gehouden wordt met nieuwe zaken zoals remote timing attacks en dergelijke. Als je dat soort dingen zelf bij wil houden fine, maar dan moet je er wel tijd voor en zin in hebben.

Succes om bijvoorbeeld dat laatste te doen binnen een afgesloten intranet, waar onze LDAP-implementatie draait. Daar heb ik dus heel bewust dat soort beveiligingen niet nodig.

Dat zeg je nu. Eerst was ZF is traag en bloated waarop overduidelijk gewezen wordt op benchmarks van OOP/MVC framework stacks, iets wat hier compleet niet van toepassing is. Dat Zend_Auth in jou ogen bloated is, dat kan. Traag, neej, minder snel, misschien. Hardware is nog altijd cheaper dan een developer zeggen ze hier dan.

Ik heb nergens gezegd dat het traag was. Ik heb wel gezegd dat het trager is dan native code. Verder heb ik alleen de woorden "log" en "bloated" gebruikt, en die gaan alleen indirect over performance. Als ik "traag" als argument zou gebruiken, dan was het eerder "trager dan strikt noodzakelijk".

Ik haal toch iets heel anders uit die blogpost:

Hij ontkracht daar het nut van benchmarks door zelf een oneerlijke benchmark te doen (waar die van Cheatah bijvoorbeeld wél eerlijk was) en vervolgens te zeggen dat je ze kan manipuleren. Zo ken ik er nog wel een paar. Benchmarks in gelijke omstandigheden en met vergelijkbare settings hebben wel degelijk nut, en deze meneer probeert dat alleen te ontkrachten omdat ZF zo slecht uit de bus komt bij dergelijke benchmarks. Wat niet wil zeggen dat het een slecht framework is, hooguit dat het zoveel dingen probeert te doen dat het een aanslag op de performance maakt.

Je moet mij niet voor mijn voeten gooien dat ik de TS Zend_Auth aangeraden heb, ik zie ook niet in waarom ik dat dan zou moeten verdedigen. Ik kom alleen maar vragen waarom jullie daar (en wel vaker) het gehele framework afkraken met argumenten over traag, log en bloated terwijl er helemaal niet gepraat wordt over het gebruik van ZF. Iemand biedt Zend_Auth aan en jullie vallen over elkaar heen om ZF de grond in te boren om je naderhand zacht uit de hoek te komen met: "Ja maar frameworks, classes, whatever eigenlijk allemaal niet nodig, zelf doen"

Dat maak jij ervan. Het begon allemaal met MueR die alleen zei dat het nergens op sloeg om het Zend Framework voor deze simpele toepassing aan te raden. Daarna werd er vanuit verschillende kanten fel gereageerd op de woordkeuze "log". Intussen wordt er nog steeds geen reden aangedragen waarom je het vooral wél moet gebruiken voor een simpele SSO m.b.v. AD.

Jij hebt de discussie afgesplitst ja, dat had ik meteen al door. Een non-biased geinteresseerd iemand had er van gemaakt [PHP] Frameworks, wanneer wel, wanneer niet en welke?. Dit topic siert je helemaal niet. Call me Calimero, call me what you will.

Het gaat in het hele topic al alleen maar over ZF... Sowieso heb ik geen bias (vooroordeel) maar een mening, en dat zijn nogal twee verschillende dingen. Maar goed, jij je zin, titel aangepast.

Jullie hebben het ook niet afgeraden, ZF wel en dat bedoel ik.

"Hoi, ik wil een nieuwe auto en heb hierbij een goedkoop Trabantje gevonden, maar die wil ik liever niet. Weet er iemand een betere auto?"
- "Die Trabant moet je niet nemen!"

De topicstarter heeft die class zelf al afgeraden, wat voeg ik in godesnaam aan een topic toe door nog eens te zeggen dat hij het niet moet gebruiken?

[Verwijderd]

iH8 schreef op dinsdag 23 november 2010 @ 17:12:

Dat zeg je nu. Eerst was ZF is traag en bloated waarop overduidelijk gewezen wordt op benchmarks van OOP/MVC framework stacks, iets wat hier compleet niet van toepassing is. Dat Zend_Auth in jou ogen bloated is, dat kan. Traag, neej, minder snel, misschien. Hardware is nog altijd cheaper dan een developer zeggen ze hier dan.

Oh, maar daar zit ik helemaal niet mee. Ik beheer servers, en een server extra beheren doe ik graag.

Je wilt overigens niet weten hoe vaak het voorkomt dat een server tegen zijn limieten aan zit omdat de developers niet in staat waren iets te bouwen dat iets betere performance heeft.

[Verwijderd]

NMe schreef op dinsdag 23 november 2010 @ 17:36:
Dat maak jij ervan. Het begon allemaal met MueR die alleen zei dat het nergens op sloeg om het Zend Framework voor deze simpele toepassing aan te raden. Daarna werd er vanuit verschillende kanten fel gereageerd op de woordkeuze "log". Intussen wordt er nog steeds geen reden aangedragen waarom je het vooral wél moet gebruiken voor een simpele SSO m.b.v. AD.

Beste man, het begon allemaal met MueR die een kortzichtige opmerking maakte, op basis van een blijkbaar verkeerd getrokken conclusie dat hier werd geadviseerd om een compleet framework te gaan gebruiken voor een simpele opdracht als dit. Terwijl er toch echt 3 of 4 keer in die desbetreffende thread duidelijk wordt gezegd door meerdere mensen (waaronder mijzelf) dat het advies betrof om juist één enkel component te gebruiken van dat framework, zonder alle overhead die een MVC-stack met zich mee brengt.
Je kunt nu natuurlijk wel de vicieuze cirkel doorzetten en nu weer gaan roepen dat het onzin is om een compleet framework te gebruiken voor een simpele opdracht en dat je véél beter zelf iets kunt schrijven, maar dan gaan we er niet uit komen denk ik. Deze hele discussie is gebaseerd op een misopvatting.

[NMe]

Verwijderd schreef op woensdag 24 november 2010 @ 12:59:
[...]



Beste man, het begon allemaal met MueR die een kortzichtige opmerking maakte, op basis van een blijkbaar verkeerd getrokken conclusie dat hier werd geadviseerd om een compleet framework te gaan gebruiken voor een simpele opdracht als dit.

...

MueR schreef op zondag 21 november 2010 @ 13:57:
PHP heeft daar gewoon native ondersteuning voor? Waarom iedereen toch elke keer aankomt met dat logge ZF is me een raadsel.

MueR uit zijn frustratie over het feit dat het ZF steeds en steeds vaker als oplossing wordt aangeboden voor elk klein kloteprobleempje, net zoals hier. Zend_Auth heeft een paar quirks, zoals Freeaqingme (die er nota bene verstand van heeft) al zegt. Die quirks vermijd je door simpelweg 3 functiecalls naar functies in het standaardpakket van PHP aan te roepen. Al sinds die opmerking van MueR wordt het gezien als een kruistocht naar ZF, maar het is gewoon wat het is: het advies om het in dit geval niet te gebruiken omdat je zónder net zo ver komt in evenveel tijd. Nogmaals: use the best tool for the job.

[MueR]

Nou zeg, lig ik een keer een paar dagen ziek op bed, is het meteen heisa.

Verwijderd schreef op woensdag 24 november 2010 @ 12:59:Beste man, het begon allemaal met MueR die een kortzichtige opmerking maakte, op basis van een blijkbaar verkeerd getrokken conclusie dat hier werd geadviseerd om een compleet framework te gaan gebruiken voor een simpele opdracht als dit. Terwijl er toch echt 3 of 4 keer in die desbetreffende thread duidelijk wordt gezegd door meerdere mensen (waaronder mijzelf) dat het advies betrof om juist één enkel component te gebruiken van dat framework, zonder alle overhead die een MVC-stack met zich mee brengt.

Bedankt dat je elke opmerking tegen ZF meteen als kortzichtig afschildert, toont hoe je in de discussie staat: hakken in de sloot en niemand mag het geweldige ZF afkraken. Nou, here goes..

Zend Framework is log, bloated en absoluut overbodig voor de meeste toepassingen. Zelfs een enkel component. Ik heb zojuist even gekeken naar de totale grootte van ene component wat ik laatst heb moeten gebruiken: de GData api. Welgeteld 3 mb aan code, waarvan 2.2mb puur het GData component betreft. Dan is er nog 172kb aan HTTP, 544kb aan Validate en 32kb aan URI.

Het gebruik van ZF is ook nou niet je van het. Magic loaders galore, wat imho altijd een minpunt is voor onderhoud. Wellicht dat er slimmere manieren zijn om dat spul te laden, zoals iH8 in "Standaard frameworks in PHP: wanneer wel..." aangeeft, maar dat is niet in de documentatie te vinden.

Dan het puntje performance. Ik ben teleurgesteld. De complete pakketten die ik heb zien draaien presteren gewoon echt diep, diep, diep droevig, zelf op een enorm dikke webserver die uit zn neus staat te eten met 0.01 load. Maar dat ligt uiteraard aan de programmeurs die dat pakket gebouwd hebben?

Ook de GData API gaat mij gewoon veel te traag. Bij tests met eigen code haalde ik gewoon betere response tijden (zowel op de query naar google/youtube als op het parsen van de resultaten). Sorry hoor, maar dan heb je bij mij afgedaan als framework. Dat het jullie werk makkelijker maakt, prima, dat geloof ik direct. Echter, wanneer de site er merkbaar/meetbaar trager door wordt, houdt het voor mij op.

Deze hele discussie is gebaseerd op een misopvatting.

Voornamelijk jullie misopvatting dat ik zomaar wat roep.

NMe schreef op woensdag 24 november 2010 @ 13:27:
MueR uit zijn frustratie over het feit dat het ZF steeds en steeds vaker als oplossing wordt aangeboden voor elk klein kloteprobleempje, net zoals hier.

Dit speelt ook mee. In PHP topics wordt regelmatig door iemand "gebruik toch ZF" geroepen. Ja leuk, maar waarom dan? Zeker voor iets waar PHP native ondersteuning voor heeft. Dit is niet exclusief voor ZF overigens. Hetzelfde gebeurt met jQuery, dat wordt ook door iedereen te pas en te onpas naar hoofden geslingerd. Na een tijdje begin je je af te vragen of de mensen die het gebruiken nog wel weten wat zelf PHP/JS schrijven inhoudt.

Al sinds die opmerking van MueR wordt het gezien als een kruistocht naar ZF, maar het is gewoon wat het is: het advies om het in dit geval niet te gebruiken omdat je zónder net zo ver komt in evenveel tijd. Nogmaals: use the best tool for the job.

Exact.

[Verwijderd]

MueR schreef op woensdag 24 november 2010 @ 15:25:
Bedankt dat je elke opmerking tegen ZF meteen als kortzichtig afschildert, toont hoe je in de discussie staat: hakken in de sloot en niemand mag het geweldige ZF afkraken. Nou, here goes..

Graag gedaan. Wat je zegt klopt alleen voor geen meter, maar oké.

Zend Framework is log, bloated en absoluut overbodig voor de meeste toepassingen. Zelfs een enkel component.

Over hakken in de sloot gesproken. Zodra jij en NMe jullie meningen en ervaringen gaan verkondigen als onomstootbare feiten, kap je zelf de discussie af. Wanneer je een zin eindigt met "Waarom iedereen steeds aankomt met dat logge ZF is me een raadsel" is dat niet met nuance en argumenten je mening geven, maar eerder een quasi-flame.

Ik ga er verder geen woorden aan vuil maken. Jullie weten het blijkbaar zó goed, dat jullie eigen code hoe dan ook beter werkt dan het "logge" ZF. Het is niet alleen de gebrek aan nuance en argumentatie, maar ook de arrogantie die dergelijke reacties met zich mee brengt is gewoon rete-irritant. Waar jij zegt dat ik z.g.n. elke reactie jegens ZF afschilder als kortzichtig, zou ik liever willen zeggen dat jullie elke reactie pro-ZF per definitie afschilderen als "je weet niet waar je het over hebt" en "je kan veel beter eigen code schrijven". Dat is niet discussiëren, maar drammen om je gelijk te halen.

Nou, bij deze: gefeliciteerd.

[ Voor 7% gewijzigd door Verwijderd op 25-11-2010 10:49 ]

[NMe]

Je gaat niet eens in op mijn discussiepunten en ik heb nog steeds geen geldige reden gezien om wel die klasse te gebruiken. In plaats daarvan ga je mierenneuken op woordkeuzes. "Log" is geen belediging maar een constatering. Een direct effect van zoveel mogelijk features willen bieden voor zoveel mogelijk situaties is dat je code groter wordt. Groter dan strikt noodzakelijk voor kleine probleempjes zoals die van de TS van het oorspronkelijke topic. Dat heet log, en da's geen mening maar een feit. "Bloated" is min of meer synoniem maar met een negatievere bijsmaak, dus daar zit wel mijn mening over ZF in verwerkt.

Dus nogmaals, in plaats van steeds te hameren op de wat fellere woordkeuze zou ik het leuk vinden als jullie eens met een goede reden komen waarom ZF in deze situatie beter is dan een zelf geschreven stuk code dat evenveel tijd kost.

[mithras]

Wat een discussie over mijn "simpele" suggestie

Ik denk dat beide kanten best gelijk hebben, maar voorbij gaan aan één simpel feit: het grijze gebied tussen zwart en wit is vele malen groter! Het altijd gebruiken van een framework (koste wat kost) is overdreven. Het nooit gebruiken van een framework is constant het wiel opnieuw uitvinden en jezelf laten verdrinken in het grote "ik weet het beter" moeras.

Als ik kijk naar de suggestie van NMe in Gebruikers valideren in AD met PHP brrr, dat zou ik nooit gebruiken. Je gaat geheid tegen de lamp lopen als je een kleine uitbreiding in het systeem wil aanbrengen. Aan de andere kant, je zal natuurlijk nooit een heel framework importeren als je slechts een simpele login/checkup nodig hebt. Ik denk desalniettemin dat sowieso het bekijken van een bestaand framework zeer nuttig kan zijn. omdat je zaken tegen zal komen waar je zelf pas achterkomt in een later (te laat) stadium.

Zelf ben ik drie jaar geleden tot het inzicht gekomen dat ik niet eigenwijs moet zijn, niet alles zelf moet doen en vooral de tools van anderen gebruiken. Mijn ervaring: wanneer je, met een gedegen afweging, een framework inzet bespaar je 50% aan ontwikkeltijd. Van die andere tijd kan je de helft besteden aan het verbeteren van de prestaties om op een goed niveau te komen, maar alsnog ben je sneller uit dan alles zelf gaan programmeren. En dan heb ik het nog niet gehad over testbaarheid, onderhoudbaarheid en uitbreidbaarheid

[NMe]

mithras schreef op donderdag 25 november 2010 @ 13:17:
Ik denk dat beide kanten best gelijk hebben, maar voorbij gaan aan één simpel feit: het grijze gebied tussen zwart en wit is vele malen groter! Het altijd gebruiken van een framework (koste wat kost) is overdreven. Het nooit gebruiken van een framework is constant het wiel opnieuw uitvinden en jezelf laten verdrinken in het grote "ik weet het beter" moeras.

Ik zeg ook nergens dat je het nooit moet gebruiken; ik zeg dat het hier niet wenselijk was in mijn ogen.

Als ik kijk naar de suggestie van NMe in Gebruikers valideren in AD met PHP brrr, dat zou ik nooit gebruiken. Je gaat geheid tegen de lamp lopen als je een kleine uitbreiding in het systeem wil aanbrengen. Aan de andere kant, je zal natuurlijk nooit een heel framework importeren als je slechts een simpele login/checkup nodig hebt.

Dat was inderdaad de overweging. De structuur in AD blijft hetzelfde; gebruikersinfo ophalen doe ik met een andere functie maar dat kan Zend_Auth bij mijn weten ook niet zomaar.

Ik denk desalniettemin dat sowieso het bekijken van een bestaand framework zeer nuttig kan zijn. omdat je zaken tegen zal komen waar je zelf pas achterkomt in een later (te laat) stadium.

Daarom heb ik destijds ook naar ZF gekeken en de keuze gemaakt om het niet te gebruiken, om veelal dezelfde redenen die ik hierboven aandraag.

[kwaakvaak_v2]

Het probleem met het hebben van een stellige mening dat het niet te gebruiken is,is dat je die mening eigenlijk elk jaar bij moet stellen.

In het verleden gehaalde resultaten hebben bij frameworks eigenlijk zelden een garantie voor de toekomst.

Kijk ik bijvoorbeeld naar symfony, 1 jaar geleden vond ik het symfony framework maar een raar gedrocht. Nu recent de eerste versies van symfony2 het daglicht hebben gezien, moet ik denk ik die conclusie bijstellen. Puur omdat dat de makers van dat framework, net als elke andere goede ontwikkelaar geleerd hebben van fouten en andere inzichten, en daarop ingespeeld hebben in de manier waarop zaken binnen het framework geregeld worden.