Opmaak PHP of jQuery
Uit de database haal ik gegevens op met een AJAXcall nu wil ik die presenteren in een tabelvorm.
Is het technisch beter om een Json terug te sturen en de volledige opmaak door jQuery/Javascript te laten doen. Of stuur ik vanuit PHP al een tabel terug?
Ik ben erg benieuwd wat jullie zouden doen en waarom :-)
Hangt van de complexiteit af. Als het nagenoeg een complete tabel-body is van redelijk wat data dan zou ik dit gewoon als één lap HTML terugsturen. Je kunt dan namelijk in PHP alles al regelen zoals het genereren van hyperlinks, het escapen van output et cetera zodat jQuery enkel de inhoud van een placeholder hoeft te vervangen met een of ander leuk effectje. Dat is ook beter uit oogpunt van een soort van separation of concerns. Het lijkt mij niet optimaal om in JavaScript complexe/uitgebreide HTML te gaan breien.
Zelfs als er jQuery-interactie is met die inhoud dan hoef je niet per se on-the-fly allemaal event handlers te koppelen aan de nieuw gecreëerde/ingevoegde elementen als je een gedelegeerde aanpak gebruikt. Dus ook uit oogpunt vanuit techniek hoeft dit geen obstakel te vormen.
Het is niet zozeer beter (of slechter) maar gewoon makkelijker.
Dit wordt natuurlijk een ander verhaal als je niet op voorhand weet hoe deze informatie gebruikt gaat worden, dus als je een soort van webdienst hebt ofzo.
Je zou beide zelfs kunnen combineren. jQuery roept een PHP script aan die een tabel genereert op grond van opgehaalde JSON data van een informatiedienst.
Dit is ook een erg brede vraag - zoals met zoveel dingen hangt het van de toepassing af :p. Er is geen eenduidig antwoord. In plaats van je af te vragen waarom je iets (wel) zou doen zou je je ook kunnen afvragen of er redenen zijn om iets niet op een bepaalde manier aan te pakken. En dit soort argumenten voor en tegen zul je moeten wegen, deze kun je niet simpelweg tellen.
- Als je een AJAX call doet roep je dus eigenlijk een soort API aan, en een API retourneert wat mij betreft het liefst altijd "zuivere data" - dus geen lappen HTML. D'r zijn natuurlijk altijd uitzonderingen, maar de inhoud van een tabel kwalificeert meestal toch wel als zuivere "data". Uitgangspunt van deze gedachtegang is dat het later heel makkelijk is om de (gestructureerde) data "anders" te gebruiken (door iemand anders).
- Geen idee hoe groot die tabel is, maar als het "heel veel" records zijn, kan het de moeite waard zijn om de tabel "on demand" te vullen. Dus eerst (bijvoorbeeld) 100 records tonen, en pas als de gebruiker naar beneden begint te scrollen de volgende 100 records toevoegen, enz.
Rob Doemaarwat op 03/12/2019 21:25:37:
Uitgangspunt van deze gedachtegang is dat het later heel makkelijk is om de (gestructureerde) data "anders" te gebruiken (door iemand anders).
Mja, dus herbruikbaarheid is een argument om dingen generiek op te zetten. Maar als je de enige bent die hier gebruik van maakt (intern gebruik) is dat niet direct nodig.
Daarnaast zou je kunnen kijken hoe breed dit alles ingezet zou moeten worden, en hoever deze opzet dient te worden uitgekristalliseerd.
Op een gegeven moment moet code een soort concreet eindresultaat produceren. Je zou je kunnen afvragen hoeveel abstracte tussenstappen echt nodig zijn.
Als programmeur kan het geen kwaad om stil te staan bij het verschil tussen "afstand" en "afgelegde weg", en de vraag of een touristische route echt wat oplevert. Houd dingen zo simpel mogelijk, maar niet simpeler. Als zo'n abstractielaag inzetbaar is is het misschien de moeite waard om te maken, maar anders niet. Dan lijkt mij dit extra werk voor niets. En als het later nodig blijkt kun je dat dan alsnog bijbouwen. En je zou in het ontwerp hier al in kunnen voorzien, wil niet zeggen dat je het ook allemaal in 1x zou moeten implementeren.
Ik zie dat er dus geen wet is hoe ik het doe. Dit topic heb ik geopend om te kijken wat het praktische / handigste is.
Gelukkig heeft ieder zijn eigen stijl :)
Ik kan ieder geval verder :-)