Ok zoals misschien sommigen al weten ben ik momenteel mijn kennis aan het vergroten qua php ed.
Om mijn kennis te vergroten en me in veel zaken te verdiepen ben ik voor mezelf (eigen gebruik) een sms aan het maken. Op die manier kom ik VEEL tegen en leer ik voor mijn gevoel veel.
Waar ik nu tegenaan loop is het volgende:
Ik weet soms pas hoe mijn top vd pagina/menu er UITEINDELIJK uit moet komen te zien als ik bij mijn footer aankom. Waarschijnlijk is mijn aanpak dan niet goed. Mijn vraag is, hoe kan ik mijn pagina opbouwen maar toch nog aanpassen tijdens het opbouwen? Ik weet dat je bijvoorbeeld met jQuery zaken welke al staan kan verwijderen/aanpassen etc. Maar of dit nou de manier is?
Ik vraag mijzelf af wat nu de "beste" manier is.
Ik vraag nu niet om dit nu voor mij helemaal te gaan uitkauwen en mij alles te vertellen. Wat vraag ik dan wel?
Kan je mij op weg helpen met zoektermen, tuts of sites? Ik zoek wel al maar vind niet. Waarschijnlijk omdat ik niet weet welke termen te gebruiken.
Ik zoek het dan zelf uit en ga me dan inlezen. Daar leer ik denk ik het meeste van.
Is het niet mogelijk om eerst alle informatie te verzamelen die je nodig hebt en dan pas beginnen met opbouwen van je pagina?
In principe hoef je dan niet terug te grijpen om je pagina te manipuleren.
Om mijn kennis te vergroten en me in veel zaken te verdiepen ben ik voor mezelf (eigen gebruik) een sms aan het maken.
Je bent een sms aan het bouwen? Een sms is een berichtje wat je per telefoon verstuurt. Bedoel je wellicht een CMS?
Daarnaast ... ik snap niet wat je bedoelt met als je bij de footer bent dat je dan pas weet wat er bovenin moet komen te staan. Kun je dat wat beter toelichten?
Ik typte toch echt CMS. Maar autocorrect....
@Jan Ja dat is eigenlijk wat ik bedoel. Maar weet ff niet hoe dat aan te pakken. Kun jij me ergens op weg helpen?
Dat is dus een kwestie van eerst zorgen dat je alle intelligentie ophaalt, en daarna pas de pagina gaan opbouwen.
Vergelijk het met eten bestellen in een restaurant. Eerst wordt gevraagd wat je wilt hebben, en daarna worden de recepten bereid en op je tafel geplaatst. Wat jij nu doet is eerst een paar gerechten op tafel zetten en daarna eens gaan vragen wat de klant eigenlijk wil hebben.
Mja, maar het complete menu staat niet altijd op voorhand vast, bij de opbouw van een pagina kan het zo zijn dat het hoofdgerecht van invloed is op het voorgerecht om het zo maar te zeggen. Code die in de header ingeladen dient te worden (document titel, javascript- en CSS-bestanden) zou bepaald kunnen worden in het content-deel van de pagina. Je komt dan in de knoei met de volgorde van het weergeven van de content ten opzichte van de volgorde die in de code aangehouden moet worden om in eerste instantie te bepalen welke content je nu eigenlijk hebt.
Dit probleem zou je kunnen oplossen door output op te sparen door middel van output buffering; je voert de code in een logische volgorde uit zodat je je administratie voor de opbouw van de pagina kunt verrichten en zet output buffering in daar waar de volgorde van weergave in het document afwijkt van de volgorde van de code. Vervolgens druk je alle stukjes in de goede volgorde af.
>> Mja, maar het complete menu staat niet altijd op voorhand vast, bij de opbouw van een pagina kan het zo zijn dat het hoofdgerecht van invloed is op het voorgerecht om het zo maar te zeggen.
Dus voer je eerst alle intelligentie uit, anders gezegd haal je eerst alle benodigde data op. Pas daarna ga je dan je view renderen en geef je die data mee aan je view.
>> Dus voer je eerst alle intelligentie uit, anders gezegd haal je eerst alle benodigde data op. Pas daarna ga je dan je view renderen en geef je die data mee aan je view.
Volgens mij levert zo'n stricte scheiding ook een hoop overhead op; als je een stuk functionaliteit hebt waarbij je dingen on-the-fly in kunt stellen maar die ook output produceert dan kun je dit oplossen met output buffering. Ook doe je in jouw geval dan dingen dubbel als je het mij vraagt, deze kun je combineren.
Stel dat je bijvoorbeeld een stuk functionaliteit hebt die een formulier weergeeft (als onderdeel van het genreren van een compleet HTML document). Dit formulier heeft tevens een apart CSS-bestand (even los van alle optimalisatie daarvan). Dit CSS-bestand zou je dan in de header van je HTML-document in willen voegen, als onderdeel van een of ander (hoger gelegen) maintemplate.
Door het uitvoeren van deze "actie" (het instrueren van het maintemplate om een extra CSS-bestand in te laden en het weergeven van de HTML-code van het formulier met gebruikmaking van output buffering) sla je volgens mij twee vliegen in een klap. Deze actie moet je sowieso eerst uitvoeren omdat deze bepalend is voor het uiteindelijke HTML-document (waarin een CSS-bestand zit specifiek voor die actie).
Als je dit bovenstaande voorbeeld niet kunt volgen is het waarschijnlijk moeilijk uit te leggen wat ik bedoel.
Hoe zou je dit met een hele stricte scheiding voor elkaar krijgen? Je pagina heeft een vaste opmaak (vast maintemplate) met hierin een variabel deel (de "content") waarin een formulier wordt geladen waarmee je een CSS-bestand in wilt voegen in de vaste opmaak. Volgens mij is dan een slim gebruik van output buffering de eenvoudigste manier.
Output buffering wordt juist meestal afgeraden wegens performance issues. En inderdaad zinspeel ik dan op een MVC-achtige aanpak. Vanuit je form action zou je dan het benodigde css bestand kunnen meegeven aan (uiteindelijk) je main template. Als allerlaatste ga je dan pas je view renderen, waarbij je css bestanden dynamisch in je main template worden geinjecteerd.
Performance? Really? In this day and age? Lijkt me trouwens ook afhangen van de snelheid waarmee je pagina wordt opgebouwd, indien dit redelijk traag is blijft deze langer resources claimen en dan krijg je misschien een sneeuwbaleffect. En de output compressie (gzip) die je daarmee kunt regelen? Daarmee kan ik een tekst document van ca 200 kb reduceren tot ca 35.5 kb, dat vind ik nou niet bepaald misselijk. Daarmee is je document ook sneller over de lijn. Er zal ergens een omslagpunt liggen? Ik zeg ook niet dat je alles moet output bufferen he (met uitzondering natuurlijk als je gzip compressie gebruikt; dit zal het hele document moeten betreffen), enkel die snippets die niet in de goede volgorde staan.
Heb je (recente) artikelen waarin aannemelijk wordt gemaakt dat het gebruik van output buffering wellicht niet zo'n goed idee is uit oogpunt van performance? Ben wel benieuwd eigenlijk.
Goede vraag, dat zou je dan moeten testen. Ik weet wel dat hier op het forum (inmiddels wel een paar jaar geleden) altijd gezegd werd dat je het altijd moest vermijden vanwege performance issues. Maar dat is dus al even geleden. Maar goed, erover nadenkend ... je stopt iets in het geheugen dus het kost sowieso wat resources. Afhankelijk van hoeveel je erin stopt, kan ik me voorstellen dat het bij grotere bezoekersaantallen vertragend zou kunnen werken. Misschien kan iemand anders er nog iets over zeggen.
