Pagina manipuleren
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.
Alvast dank!
In principe hoef je dan niet terug te grijpen om je pagina te manipuleren.
Gewijzigd op 11/01/2016 20:14:25 door Jan de Laet
Sander Z op 11/01/2016 19:29:34:
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?
@Jan Ja dat is eigenlijk wat ik bedoel. Maar weet ff niet hoe dat aan te pakken. Kun jij me ergens op weg helpen?
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.
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.
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.
Je zinspeelt in jouw aanpak ook op MVC?
Gewijzigd op 11/01/2016 23:03:21 door Thomas van den Heuvel
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.
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.
Sander Z op 11/01/2016 19:29:34:
Dan verwar je twee dimensies: ruimte en tijd. De leesrichting van een webpagina (ruimte) hoeft niet te bepalen in welke volgorde een pagina wordt opgebouwd (tijd). Je kunt best een ontwerp hebben waarin het resultaat van setFooter() de input van setHeader() bepaalt.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.
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.
Ik denk dat je je eens moet verdiepen in de concepten van objectgeoriënteerd programmeren. En dan bedoel ik niet eens MVC (want daarin kun je dit probleem ook hebben), maar bijvoorbeeld SOLID-beginselen zoals het Single Responsibility Principle (SRP). Je hebt nu namelijk één ding dat minstens twee dingen doet: tijdens het opbouwen van de pagina wordt niet enkel en alleen de pagina opgebouwd, maar gebeurt er kennelijk nog iets anders.
Gewijzigd op 12/01/2016 09:21:37 door Ward van der Put
Misschien eerst een brainstormsessie doen. Of bijvoorbeeld een interactiemodel maken, of een model met alle mogelijke functies binnen de site die je wil hebben.. En dan de opbouw bedenken en die uitvoeren.
Maar thanks voor alle info. Ik ga hier even verder mee. Ik zal hoogstwaarschijnlijk nog wel een vraag gaan krijgen ;)