[ajax]welke data laat je inladen en welke juist in de HTML?

[djluc]

Ik ben bezig met een roostersysteem. Het belangrijkste scherm hierin is een maand-overicht met alle dagen (1-31) en alle gebruikers. Dit is een grote tabel, in elke cel staat een selectbox waarmee je de dienst kan aanpassen.

Bij elke wijziging wordt een JS aangeroepen wat de wijzigingen naar de server stuurt en het scherm update met nieuwe informatie.

Mijn vraag: Hoe pak je dit aan? Ga je de data die al in de database staat gewoon met PHP hardcoded in de tabel zetten? Of ga je juist, zoals bijvoorbeeld op http://start.com , alles middels JS laden nadat de pagina geladen is? Ik kan hier geen voorbeelden van vinden over wat wel en niet handig is.

Het voordeel van het vooraf in de HTML plaatsen is dat de pagina sneller geladen is. Dit gebeurt tenslotten allemaal al op de server en zonder de tussenstap van ajax. Daarentegen moet je wel meer PHP ontwikkelen omdat je zowel een PHP als een ajax stukje moet ontwikkelen. Wie heeft hier ervaring mee, wat is handig en wat juist niet?

[orf]

Zo veel formuliervelden worden meestal erg traag bij bijvoorbeeld scrollen. Ik zou ervoor kiezen om met javascript de tabel te genereren (minder bandbreedte door het weglaten van veel html).
De cellen zou ik niet vullen met selects, maar gewoon een tekstuele weergave. Met een javascript functie kun je de cell een onclick event geven. Met behulp van DOM kun je dan de tekstuele weergave vervangen voor een <select>.

Het is altijd een afweging wat sneller is. Is een pagina van 100kb HTML sneller gedownload door de client dan 20kb die daarna nog door een javascriptfunctie moet.

[djluc]

Bedankt voor je reactie!

Even over dit puntje:

orf schreef op dinsdag 22 november 2005 @ 11:38:
Het is altijd een afweging wat sneller is. Is een pagina van 100kb HTML sneller gedownload door de client dan 20kb die daarna nog door een javascriptfunctie moet.

In principe is het natuurlijk dezelfde hoeveelheid data die ik wil verzenden. Alleen is de overhead natuurlijk een stuk groter als je met JS elke keer een cel ophaalt van de server. Dat gebruikt dus in principe meer data.

[orf]

ik bedoelde de data in een ander formaat, stel dat je dit aanmaakt met PHP:

echo 'arr = new Array("a", "b", "c", "d")';

Als je voor javascript geneste arrays bouwt, kun je met javascript de tabellen gaan genereren:

var html = '';
for (i=0; i < 100){
html += '<td>' + arr[i] + '</td>';
}

Met geneste arrays bespaar je zo heel veel html die niet naar de browser gestuurd hoeft te worden.

[JHS]

orf schreef op dinsdag 22 november 2005 @ 11:38:
(minder bandbreedte door het weglaten van veel html). (...) Het is altijd een afweging wat sneller is. Is een pagina van 100kb HTML sneller gedownload door de client dan 20kb die daarna nog door een javascriptfunctie moet

Het overgrote deel van de mensen download een pagina, dacht ik, inmiddels sneller dan dat er gerendert wordt met behulp van js, indien de server snel genoeg is, en afhankelijk van de doelgroep natuurlijk. Iniedergeval is het "tegenwoordig" volgens mij niet meer zo dat bandbreedte vanuit een snelheidsperspectief in de trand van KB's nog als enorme optimalisatie geld .

@ djluc: Volgens mij is het gebruikelijk / verstandig, unobtrusive javascript in gedachte houdend, de pagina serverside op te bouwen en in HTML te presenteren, en vervolgens pas met ajax de pagina aan te gaan passen. Op zo'n manier dat als je js hebt uitgeschakeld, het ook werkt, dus door een normale request te doen aan de server indien nodig.

[djluc]

Dat is inderdaad een interessante insteek JHS. Ik ben even aan het bedenken of de applicatie uberhaupt functioneel zou kunnen zijn als ik geen JS gebruik. Ik zou dat niet functioneel kunnen krijgen zonder veel extra werk te doen. Dat is dus niet echt noodzakelijk omdat het een webapplicatie is die nou eenmaal JS nodig heeft. Voor een website zou ik het inderdaad wel zo aanpakken. De applicatie is echter totaal niet bruikbaar als je geen JS hebt.

[JHS]

Aangezien GMail ook volledig in clean HTML werkt, ben ik wel benieuwd voor applicatie dat dan is . Overigens, met bijvoorbeeld Rails roep je dezelfde actie aan met ajax, als met een conventionele request. Alleen de output manier verschilt (inclusief of exclusief layout / template aanroep). Mits je programma opzet dus daarvoor geschikt / goed is, hoeft dat helemaal niet zoveel extra werk te vormen . Maargoed, die programma opzet kost, buiten bijvoorbeeld Rails gerekend, tijd, dus geld, en hoeft inderdaad niet altijd noodzakelijk te zijn .

[djluc]

Ik zal even iets meer informatie geven over de applicatie:
Het is een rooster applicatie. Je ziet dus een rooster van een volledig rooster van een maand. Zie het screenshot:

Dit is dus een klein stukje van het geheel, normaal gesproken zijn het zo'n 30 dagen. Dit wordt gebruikt binnen meerdere bedrijven. Daar is echter altijd JS aanwezig zoals normaal is lijkt mij. Zo hebben jullie misschien een beter idee van de applicatie.

[JHS]

Intranetten zijn natuurlijk altijd controleerbare omgevingen waar andere eisen gesteld worden inderdaad .

[djluc]

Ok, ik heb wat getest en ga het volgende doen:
-Tabellen e.d. die al meteen zichtbaar moeten zijn gewoon hard in de HTML zetten. Het genereren van een table met JS vertraagt toch wat erg.
-uitgebreide info over een cel in de tabel laat ik on-demand laden omdat dit erg veel info is die je allemaal bij het laden van de pagina al wilt laten laden
-simpele acties als een rij verwijderen laat ik door JS doen. Die stuurt dus een ajax-request naar de server en verwijdererd de rij.

Hoe ik formulieren ga verzenden weet ik nog niet. Ik zou dan alle veldwaarden in JavaScript moeten verzamelen en in de functieargumenten meegeven. Of dat zo'n goed idee is weet ik nog niet. Dat kost wel erg veel moeite voor een beetje gebruiksgemak.