verantwoordelijkheid... bij server of PHP-code?
Ah ja, inderdaad... nog maar eens goed over nadenken wat de juiste manier is om dit aan te pakken...
Voordeel: upgrade van apache/php en/of een verhuizing levert minder problemen op.
Nadeel: snelheid
Enige voorwaarde is wel dat de lagere snelheid niet merkbaar is (een pagina die gerenderd wordt in 0.2s ipv 0.04s is vijf keer zo traag maar natuurlijk nog steeds supersnel) en als het wel merkbaar is, deze nog steeds binnen de voor jou acceptabele grenzen ligt.
Houdt natuurlijk ook rekening met het aantal bezoekers dat je verwacht want een klein dingetje dat je nu in je script oplost kan bij gelijktijdige uitvoering door honderden bezoekers een onevenredige belasting en dus extra vertraging opleveren.
Kortom: compatibility heeft mijn voorkeur tenzij deze ervoor zorgt dat de door mij gestelde voorwaarden overtreden worden.
Toevoeging op 07/10/2014 21:37:29:
En waar zou jij dan de ini-settings regelen?
Waarom zou je dit niet doen?
- in je code lijkt het lelijk
- je weet dat er een oplossing is die sneller is
- je weet dat je bij elke pageload die stomme variabelen weer set
- je weet dat het sneller kan
- je weet dat het sneller kan
- je weet dat het sneller kan
Naar mijn mening allemaal non-argumenten want de snelheid van je pagina is prima en dat is het belangrijkste :)
Waarom zou je het wel doen?: Stel je hebt iets gemaakt dat serverinstelling afhankelijk is en uitgerold bij verschillende klanten. De ene week upgrade de ene klant, dan weer de andere gevolgd door een klant die verhuist. Deze trekken allemaal bij jou aan de bel omdat de 'website het in één keer niet meer doet' -> ARGH
Gewijzigd op 07/10/2014 21:53:45 door Frits Katoen
Frits Katoen op 07/10/2014 21:52:46:
Waarom zou je dit niet doen?
- in je code lijkt het lelijk
- je weet dat er een oplossing is die sneller is
- je weet dat je bij elke pageload die stomme variabelen weer set
- je weet dat het sneller kan
- je weet dat het sneller kan
- je weet dat het sneller kan
- in je code lijkt het lelijk
- je weet dat er een oplossing is die sneller is
- je weet dat je bij elke pageload die stomme variabelen weer set
- je weet dat het sneller kan
- je weet dat het sneller kan
- je weet dat het sneller kan
Haha, scherp! :) Dit klopt inderdaad als een bus.
Nu moet ik wel zeggen dat ik dus websites van klanten op mijn eigen server wil gaan hosten. Dus die klanten kunnen niks aanpassen. De enige die iets kan aanpassen, ben ikzelf. Dat betekent dus dat als ik zelf een Apache upgrade uitvoer of wissel van server, ik inderdaad alles opnieuw moet configureren. Maar mijn klanten hebben er geen last van. Zou jij dan toch nog steeds kiezen voor compatibiliteit? Compatibiliteit is inderdaad erg prettig, want het bespaart mij tijd en voorkomt fouten... alleen dat rijtje van jou wat hierboven staat, dat knaagt stiekem toch wel hoor, hahaha... qua extra tijd is het eigenlijk verwaarloosbaar... maar het idee dat je bij iedere pageload die variabelen weer set... aaah... dat voelt rot :)
'Ik zou het op de server instellen want dat scheelt in snelheid en resulteert in mooiere code'
Echt onderbouwen kan ik het verder niet maar volgens mij is dit wel het antwoord dat je wilt horen ;)
Oké... maar maak mij dan even duidelijk waarom het NIET stom is om die variabelen bij iedere pageload te setten... wie weet ga ik wel overstag :)