[AJAX] Is dit de juiste aanpak?

[japaveh]

Hallo,

Wij maken als sinds geruime tijd gebruik van een eigengeschreven database systeem waarbij we al onze runs met bijbehorende stappen opslaan in een database. Het idee daarachter is vrij simpel. Er bestaat een run waarbinnen soms meer dan 100 stappen voorkomen. Met PHP/MySQL wordt deze informatie opgeslagen, veranderd en opgehaald. Tot zover niets bijzonders.

Tot op heden wordt bij het ophalen van een run, alle informatie van een afzonderlijke stap (uitvoerder, start/eind-datum, remarks) uit de database opgehaald en in een tabel geplaatst. Door gebruik te maken van de KlipKlap (tm) techniek van (crisp in "Uitklapbaar menu compatibiliteit") wordt bepaalde informatie niet direct getoond maar verborgen gemaakt. En hier ontstaat het probleem.

Doordat runs soms erg lang kunnen worden, wordt de gegenereerde HTML erg omvangrijk. Daardoor duurt het (met name in IE) erg lang (>8sec) om de hele run in beeld te krijgen. FF is daar sneller in omdat deze al begint met uitvoer naar het scherm te sturen. De traagheid zit zeker in het opbouwen van het scherm, de querys worden ruim binnen een seconde afgehandeld. De enige manier om dit probleem op te lossen is volgens mij het gebruik van AJAX. Zie ik dit goed? Of is er een alternatief. Ik wil namelijk wel graag alle stappen ineens op het scherm en niet verdeeld in losse pagina's zoals dat op fora veel gebruikt wordt. Dit heeft te maken met het overzicht binnen een run.

Eerst wordt de basisinfo uit de DB gehaald en getoond en met AJAX wordt, bij het klikken op een knop. de extra info uit de database gehaald... Nu mijn vraag is eigenlijk hoe ik die extra info moet laten verschijnen... In een voorbeeld dat ik heb wordt een lege <div> gedefinieerd welke met DOM/JS wordt opgevuld met de XML data die AJAX ophaalt. Ik vraag me af, voordat ik dat ga implementeren, of dat de juiste manier is. Ik zou dan namelijk na elke stap een lege div moeten maken waardoor m'n HTMLcode weer (onnodig?) groot wordt..De afzonderlijke stappen van de run worden overigens nu niet in een <table> gezet meer met een <ul>. dit omdat ik dan ook met stappen kan schuiven om bv de volgorde te veranderen.

Sorry voor het lange verhaal, maar ik wilde de situatie zo duidelijk mogelijk schetsen. Voor de zekerheid heb ik de vragen eventjes vet gemaakt. alvast bedankt

[xtra]

IE wacht in ieder geval niet altijd met opbouwen van de pagina. Volgens mij alleen als de layout nog kan wijzigen, zoals bij de kolombreedten in een tabel.

Met poor mans ajax kun je misschien eerst een "Even geduld a.u.b." op het scherm zetten. De rest van de pagina bouw je verborgen op en als laatste verberg je de geduld-tekst en laat je de rest zien.

[Verwijderd]

AJAX is daar niet de juiste methode voor tenzij je je Run's in gedeeltes wilt weergeven ofzo waarbij je ook gewoon je output kunt opslitsen in meerder pagina's.

AJAX is eigenlijk niks meer en niks minder dan een bijeen geraapt en overhyped stel oplossingen die al eewen bestonden. en wat je met AJAX doet is eigenlijk gewoon via javascript een aparte page-request doen en die vervolgens in de bestaande pagina verwerken zodat niet de hele pagina opnieuw hoeft te worden geladen waardoor de website sneller lijkt te reageren.

wat jij moet doen is kijk naar hoe groot en vooral hoe complex je pagina is omdat dit bepalend is voor hoe lang het duurt voordat je pagina op het scherm staat. zelf zeg je al dat het 8seconden duurt voordat je pagina er is.

als je met 800Kb per seconden download is je pagina dus 8*800Kb=6400kb oftewel 6,4 Megabyte oftewel 6553600 Tekens. als elke lijn iets van 30 tekens bevat zijn dat 218453 regels en als je dat zou uitprinten kom je op 4369 bladzijde wat met 11 pagina's per minuut 397 minuten duurt oftewel je staat zo'n 6,5 uur te printen.

kortom je output is veel te groot. kijk of je dat kunt indammen. vooral als een loop ofzo gebruikt waarbij je een stukje html print, als je daar ook maar 20 tekens vanaf haalt en die loop loopt een 1000 keer is dat al zo'n 20Kb. vooral onodige en dubbele html tags of argumenten vragen veel van zo'n renderengine. firefox is dan nog zo slim dat die al begint om het moment dat de pagina binnen komt maar de pagina wordt in de achtergrond nog gewoon gedownload.

dus minderen want 6,4Mb is ERG groot.

[--MeAngry--]

Wat Docey zegt klopt en kan inderdaad de beste oplossing zijn. Maar soms kun je gewoon niet af met bijvoorbeeld minder informatie. (Overbodige tags daargelaten.)
En dan kan de AJAX-methode (om het zo maar even te noemen, ik noem zoiets liever de XMLHTTP-methode ) wel degelijk handig zijn voor zoiets.

De DIV waar die informatie in zou moeten komen te staan kun je natuurlijk met createElement ook middels een Javascript functie pas toevoegen als deze echt nodig is, dus dat hoeft ook geen probleem te zijn.

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 10:20:
wat jij moet doen is kijk naar hoe groot en vooral hoe complex je pagina is omdat dit bepalend is voor hoe lang het duurt voordat je pagina op het scherm staat. zelf zeg je al dat het 8seconden duurt voordat je pagina er is.

als je met 800Kb per seconden download is je pagina dus 8*800Kb=6400kb oftewel 6,4 Megabyte oftewel 6553600 Tekens. als elke lijn iets van 30 tekens bevat zijn dat 218453 regels en als je dat zou uitprinten kom je op 4369 bladzijde wat met 11 pagina's per minuut 397 minuten duurt oftewel je staat zo'n 6,5 uur te printen.

Ik heb zojuist de grootste run gelist, en deze is 500KB groot (aan gerenderde HTML-code). Dit is wel veel, maar zeker niet extreem. Een topic op Got met 100pp is ook ongeveer 350Kb. Ik heb in het verleden ook veel tijd gespendeerd om de HTML te vermindern, bijvoorbeeld door relatieve links te maken en breaks te verwijderen.

--MeAngry-- schreef op donderdag 01 februari 2007 @ 10:50:
Wat Docey zegt klopt en kan inderdaad de beste oplossing zijn. Maar soms kun je gewoon niet af met bijvoorbeeld minder informatie. (Overbodige tags daargelaten.)
En dan kan de AJAX-methode (om het zo maar even te noemen, ik noem zoiets liever de XMLHTTP-methode ) wel degelijk handig zijn voor zoiets.

De DIV waar die informatie in zou moeten komen te staan kun je natuurlijk met createElement ook middels een Javascript functie pas toevoegen als deze echt nodig is, dus dat hoeft ook geen probleem te zijn.

Ik noem het AJAX, maar bedoel inderdaad XMLHTTP, ik begrijp de achterliggende gedachte en ben het inderdad ook wel met Docey eens over de gehypte status van Ajax en wil het ook alleen gebruiken waarvoor het imho nuttig is. Daarom stel ik juist de vraag hier, volgens mij is het erg nuttig in deze toepassing om xmlHTTP te gebruiken omdat ik in de klassieke toepassing _alle_ info uit de DB sleur en als HTML ga renderen terwijl ik echt niet van alle stappen direct de details nodig heb. In deze toepassing zou xmlHTTP niet alleen de client ontlasten maar ook de DB zelf, er wordt per listing veel minder aanspraak gedaan op de DB zelf.

Ik zal me eens verder verdiepen in createElement, volgens mij is dat inderdaad de meest handige oplossing hiervoor.

[Verwijderd]

je kunt ajax wel gebruiken om de 'content' pas te laden waneer deze ook echt nodig is maar dat is wel erg complex omdat je 'DB' er dus ook op gebouwd moet zijn om de runs in gedeeltes per http-request te versturen. dit is wat het zo lastig maakt op een website de niet 'XMLHTTP' gebaseerd is hier naar om te zetten.

je zult de echter zowel de 'client' as de 'db' zwaarder belasten, omdat je meermaals naar je DB moet connecten en meerdere querys moet doen. echter zal dit geen groot probleem zijn tenzij je server nu al zowat bezwijkt onder de aanvragen.

echter weet ik niet of XML hierin nuttig is omdat XML nogal wat overhead kent en dus nogal groot en lomp is. afhangeklijk van hoe je informatie er uitziet is een komma-delimmeted string mischien wel de korste weg.

kortom: begin met het opsplitsen van de informatie in verschillende pagina's. pas als dat lukt kun je met javascript die pagina's in de betreffende 'div' tag laden.

maar ook op die manier is de informatie niet direct overzichtelijk beschikbaar omdat de gebruiker dus eerst weer ergens zal moeten klikken alvorens de inhoud wordt geladen.

mag ik vragen waarom je de informatie direct overzichtelijk beschikbaar wilt hebben? en wat houdt een 'run' eigenlijk precies in? ik snap dat het iets is wat veel informatie uit de DB sleurt en via PHP in HTML uitspugt. zit hier nog een bepaalde structuur in? zou het optimaliseren van je website een heel stuk makelijker maken.

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 11:29:
je kunt ajax wel gebruiken om de 'content' pas te laden waneer deze ook echt nodig is maar dat is wel erg complex omdat je 'DB' er dus ook op gebouwd moet zijn om de runs in gedeeltes per http-request te versturen. dit is wat het zo lastig maakt op een website de niet 'XMLHTTP' gebaseerd is hier naar om te zetten.

Doordat de DB genormaliseerd is, waardoor het eenvoudig is om per stap de gegevens in een XML-file te stoppen. Je krijgt dan dus per stap een losse XML file.

je zult de echter zowel de 'client' as de 'db' zwaarder belasten, omdat je meermaals naar je DB moet connecten en meerdere querys moet doen. echter zal dit geen groot probleem zijn tenzij je server nu al zowat bezwijkt onder de aanvragen.

Dat klopt. Om een volledige run nu uit de datasbase te halen worden er ongeveer 6 query's uitgevoerd. (in tegenstelling tot vroeger toen er per stap een aantal query's werd gedaan resulteren in soms 400query's voor een run met 100 stappen). Nu zal er per stap waarvan er meer info wordt opgevraagd een call nodig zijn, maar met de infrastructuur hier zal dat geen probleem zijn. Het wordt ook niet door veel mensen gebruikt. Continue refreshen om bijvoorbeeld een update te doen zal een grotere belasting zijn dan het genereren van een enkele XML-file

echter weet ik niet of XML hierin nuttig is omdat XML nogal wat overhead kent en dus nogal groot en lomp is. afhangeklijk van hoe je informatie er uitziet is een komma-delimmeted string mischien wel de korste weg.

CSV zou kunnen, maar ik prefereer toch wel XML zeker wanneer we later nog meer dingen met de informatie willen gaan doen is XML wel beter en handiger dan CSV

kortom: begin met het opsplitsen van de informatie in verschillende pagina's. pas als dat lukt kun je met javascript die pagina's in de betreffende 'div' tag laden.

maar ook op die manier is de informatie niet direct overzichtelijk beschikbaar omdat de gebruiker dus eerst weer ergens zal moeten klikken alvorens de inhoud wordt geladen.

Dat is dus nu ook zo, de gebruiker vraagt de run op, de DB geeft alle info. Met JS worden de details per run verborgen gemaakt waarna de gebruiker met de klipklap deze info terug op z'n scherm kan toveren. Probleem is dan dus dat er te veel nutteloze info meekomt.

mag ik vragen waarom je de informatie direct overzichtelijk beschikbaar wilt hebben? en wat houdt een 'run' eigenlijk precies in? ik snap dat het iets is wat veel informatie uit de DB sleurt en via PHP in HTML uitspugt. zit hier nog een bepaalde structuur in? zou het optimaliseren van je website een heel stuk makelijker maken.

Het is een systeem om alle stappen bij te houden voor het processen van onze devices hier. Het is belangrijk om te zien welke stappen er allemaal gedaan zijn en dat moet op 1 pagina staan omdat het verdelen over meerdere pagina's geen goed overzicht staat.

De stuctuur is vrij simpel:
Runtabel (RunId, FkUser, Startdate etc)
Stappentabel (StapId, FkRunId, FkUserId, FkProcessId etc)

Een run heeft dus meerdere stappen.

[soulrider]

japaveh schreef op donderdag 01 februari 2007 @ 12:59:
[...]

Doordat de DB genormaliseerd is, waardoor het eenvoudig is om per stap de gegevens in een XML-file te stoppen. Je krijgt dan dus per stap een losse XML file.

[...]

Dat is dus nu ook zo, de gebruiker vraagt de run op, de DB geeft alle info. Met JS worden de details per run verborgen gemaakt waarna de gebruiker met de klipklap deze info terug op z'n scherm kan toveren. Probleem is dan dus dat er te veel nutteloze info meekomt.

Hiermee kan ik al meedelen dat je met behulp van Ajax dit idd netjes kan oplossen.
Je DB moet per run minder info uitspuwen (wel vaker) - maar clients moeten niet wachten op info die ze toch niet gebruiken/ willen zien.
(is zoals met query's eh - waarom 'select * ...' terug geven als je met bv 'select id...' toekomt.)
en dan mbv DOM en js de elementen daar 'injecteren' in je HTML waar je ze nu gaat verbergen.

- dat laatste is wrs ook oorzaak van trage opbouw: eerst moet ie alles doorkrijgen en nadien alles gaan verwerken/opbouwen / verbergen voordat ie iets kan/mag tonen.
en als javascript uitstaat is alsnog alles zichtbaar.

//edit:
dit is ook mogelijk zonder html als je bv een functie hebt (serverside) die de nodige regels als html-code-deel teruggeeft: moet je die enkel ontvangen en weergeven via bv:

code:

 li.innerHTML = li.innerHTML + returnedtext; 
 //voeg teruggekregen html code toe aan inhoud van bovenliggend element.

(of soortgelijken)
vrij n00b-achtige manier van voorbeeld code wellicht -
maar werkend op een eigen projectje waar xml en dom teveel overhead zou geven

[ Voor 16% gewijzigd door soulrider op 01-02-2007 13:26 ]

[Verwijderd]

hmm, waarom XML gebruiken als de structuur zo simpel is? hier zou je volgensmij makkelijk 1regel per record kunnen gebruiken terwijl je via XML meerdere regels nodig gaat hebben. makkelijker voor mensen om te lezen ja, maar computer houden er niet zo van.

je kan dan met javascript die regels omzetten naar HTML code en die in je div tag pleuren. zo hoeft er minder te worden verstuurt, is je bandwijdte kleiner en je database wordt dan ook iets minder zwaar te werken omdat de HTML opmaak door javascript wordt gedaan ipv door PHP.

als het goed begrijp gaat het dus zegmaar om een boom-structuur van verschillende devices en zodra de user dus op een device klikt klapt er een lading informatie uit in 1 overzichtelijke pagina. probleem is dus dat alle devices eigenlijk al geladen zijn en javascript ze alleen weergeeft.

je zou dan ook kunnen kijken naar een iframe i.c.m. de target tag. het is mischien old-skool maar is nog steed erg effectief omdat je er gewoon niks voor hoeft te doen. ajax in een al bestaande site bouwen kan erg complex zijn. maar zoals gezegd zijn er meerdere wegen die naar rome lijden.

kortom de je hebt eigenlijk 2 opties:
1) gebruik javascript om de informatie te downloaden en in de pagina te stoppen. dit kan erg complex zijn, maar je kan dan bijvoorbeeld ook formatting aan de client-side doen.
2) je gebruikt een <iframe met een border van 0 in een floating div bijvoorbeeld waar je de pagina in laadt. hiervoor hoef je vrijwel niks aan je pagina aantepassen en ziet er uiteindelijk het zelfde uit. formatting moet je dan wel aan de server-side doen omdat je in feite een nieuwe pagina laadt.

welke optie het beste is hangt af van je huidige site. optie 2 is het minste werk maar optie 1 kan interresant zijn, maar is duidelijk meer complex terwijl het resultaat eigenlijk het zelfde is, of de extra scrollbar van het iframe moet een probleem zijn. maar dat lijkt mee niet omdat je dan juist naar beneden kan scrollen in de informatie terwijl het menu enzo blijft staan. wat juist handig is lijkt mij.

oh en iframe worden tegenwoordig perfect ondersteunt door zowat alle browsers maar sinds dat ajax overhyped is moet iedereen complex gaan lopen om 2 pagina's in mekaar te mengen tot 1 geheel. ajax is niet heilig en maakt dingen soms overbodig complex en voegt vaak weining toe.

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 13:21:
als het goed begrijp gaat het dus zegmaar om een boom-structuur van verschillende devices en zodra de user dus op een device klikt klapt er een lading informatie uit in 1 overzichtelijke pagina. probleem is dus dat alle devices eigenlijk al geladen zijn en javascript ze alleen weergeeft.

Bijna

Wij doen runs, en die runs bestaan uit verschillende stappen. Elke stap bevat informatie over die stap (wie hem uitgevoerd heeft, wat hij gedaan heeft, opmerkingen etc)

Deze applicatie laat je vanuit een pull-down een run kiezen waarna alle stappen (inclusief alle info) uit de Db wordt gehaald. RelevanteBelangrijke info is direct zichbaar, minder relevant belangrijke info wordt met JS verborgen gemaakt en kan met een simpele JS klik zichbaar gemaakt worden (klipklap). Dit omdat er anders te veel info meteen zichbaar is. Dit levert echter wel te veel HTML code op waardoor de browsers traag worden.

Het idee is dus om die minder relevante info dus met AJAX te laten ophalen om de redenen die hierboven beschreven zijn. Persoonlijk kies ik dan wel voor AJAX ipv een Iframe, gewoon omdat ik met het laatste eenmaal meer info heb. Verder draait deze applicatie hier intern waardoor er geen browserissues zijn. iedereen heeft FF > 1.5 en IE > 6. Het verhaal van Soulrider klopt dus inderdaad.

[ Voor 6% gewijzigd door japaveh op 01-02-2007 13:29 ]

[Verwijderd]

Ooit gehoord van inpakken

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 13:28:
Ooit gehoord van inpakken

Zekers, al denk ik niet dat dit hier de oplossing is. De bandbreedte en dataverkeer is niet interessant, het probleem is dat de browsers moeite die hoeveelheid HTMLcode juist te parsen. Dit is ook niet gek trouwens, maar vandaar dat ik naar een andere oplossing zoek.

[Verwijderd]

Is je html wel optimaal --> http://validator.w3.org/

Misschien kan je je html pagina beschikbaar stellen!


Probeer eerst je probleem goed te beschrijven! Daarna komen de oplossingen.

[ Voor 104% gewijzigd door Verwijderd op 01-02-2007 13:36 ]

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 13:32:
Is je html wel optimaal --> http://validator.w3.org/

Misschien kan je je html pagina beschikbaar stellen!

De pagina draait hier intern en staat vol met confidentiele data, dat kan dus niet zomaar openbaar gemaakt worden. via de Tidyplugin in FF weet ik wel dat de site valid html is, dus dat is het probleem niet.

hmm, net stond er nog een ander bericht over inpakken, maar ik vrees dat het dan alleen nog maar erge wordt. IE moet de file dan ook eerst nog uitpakken

Wat is er verder niet duidelijk? Ik heb echt geprobeerd het zo volledig mogelijk op te schrijven, maar wellicht wordt he daardoor weer onduidelijk ?

[ Voor 11% gewijzigd door japaveh op 01-02-2007 13:38 ]

[soulrider]

het html-compressed doorsturen is vooral handig bij veel verkeer over tragere connectie's
of waar het dataverkeer beperkt en/of duur is/kan zijn.

bij intranet-toepassingen is dat minder snel van toepassing dus.

Indien mogelijk zou ik aanraden om met enkele pagina's de opbouw en weergave tijd te vergelijken.
je steekt dan mss wat tijd in ontwikkeling die mogelijk verloren tijd/moeite blijkt achteraf.

Maar je kan dan ev. ook testen met collega's of zij inderdaad de pagina ook sneller ervaren.
(want een xmlhttprequest op de achtergrond kan ook zijn tijd nemen en dus kan de pagina alsnog trager aanvoelen dan voorheen.

Traag maar alles binnen kan sneller zijn alles druppelgewijs binnenkrijgen.
(vooral bij het opvragen van de verborgen gegevens)
en meten is weten - ook in het internet-wereldje

indien het inderdaad sneller ervaren wordt kan je gehele pagina's gaan ombouwen en alles netjes gaan uitdokteren wat het mooiste is qua code.
(en "even geduld..." vensters gaan voorzien bv)

(ik ben bv eerst met pure html + javascript en arrays aan de gang gegaan, om nadien die arrays via php/mysql aan te bieden en de javascript naar ajax/xmlhttprequests om te bouwen)

[ Voor 8% gewijzigd door soulrider op 01-02-2007 13:49 ]

[Verwijderd]

hmm, net stond er nog een ander bericht over inpakken, maar ik vrees dat het dan alleen nog maar erge wordt. IE moet de file dan ook eerst nog uitpakken

Je kan dan sneller data transporteren naar server naar client!. Het uitpakken neemt wel tijd in beslag, maar in totaliteit waarschijnlijk minder dan als je zonder het inpakken doet!.

Probleem: HTML pagina tonen neemt te veel tijd in beslag ( > 2 seconden)
Reden: de gegenereerde HTML is erg omvangrijk

Nu zou je moeten verantwoorden waarom de HTML erg omvangrijk is. Is er sprake van veel statische HTML? Wat is precies de dynamische inhoud...... etc etc. Misschien ajax,output buffering of IE instellingen etc etc.

De pagina draait hier intern en staat vol met confidentiele data --> stop er dan test data in?!!!

[Verwijderd]

daarom mijn advies tot het gebruik van iframe's om je pagina op te splitsen. met ajax combineer je alleen de output van vele http-request tot 1 pagina, wat gezien de grote van je html niet echt aan te raden en zeer complex is.

verminder de html en laad gedeeltes in een iframe.

[japaveh]

Verwijderd schreef op donderdag 01 februari 2007 @ 19:36:
daarom mijn advies tot het gebruik van iframe's om je pagina op te splitsen. met ajax combineer je alleen de output van vele http-request tot 1 pagina, wat gezien de grote van je html niet echt aan te raden en zeer complex is.

verminder de html en laad gedeeltes in een iframe.

De database wordt nu al ongeveer 1 jaar gebruikt en zullen per run zullen er gemiddeld gezien maar van een klein aantal stappen extra informatie worden opgevraagd. Het aantal extra http-request zal dus in de praktijk wel meevallen.

Inmiddels is de eerste code geschreven welke per stap een XML file kan genereren en de volgende stap is dus het schrijven van de JS voor het laten zien van deze informatie. De keus voor xmlHTTP ipv ifframes is puur persoonlijk en ook gebaseerd op de reeds beschikbare kennis van xmlHTTP hier.

[wizzkizz]

Persoonlijk zou ik dat ook met XMLHTTP oplossen. Alleen weet ik niet of ik zou kiezen voor XML of een JSON oplossing, JSON schijnt tig keer sneller te renderen dan XML, waardoor je bij omvangrijke data een serieus voordeel zou kunnen krijgen.

Je zou er ook voor kunnen kiezen (afhankelijk van de performance van de database) om de minder belangrijke gegevens al binnen te gaan hengelen zodra de pagina met de belangrijke informatie geladen is. Het aantal "Ogenblik geduld a.u.b." venstertjes kan dan omlaag. Weet je van bepaalde informatie dat die waarschijnlijk toch opgehaald gaat moeten worden, kun je die als eerste op laten halen. Allemaal om de gebruiker een snellere ervaring te geven. Kost wel meer performance omdat er wellicht overbodige gegevens opgehaald gaan worden, maar dat is nu ook al het geval omdat je nu ook al alle gegevens ophaalt en uitspuugt.

En compressed sturen? Als ik het zo lees, gaat het over een intern netwerk, waarbij bandbreedte geen enkele issue is en compressie dan zowel op de server alsook op de client tijd in beslag neemt, die dus onnodig is.

[japaveh]

wizzkizz schreef op vrijdag 02 februari 2007 @ 21:13:
En compressed sturen? Als ik het zo lees, gaat het over een intern netwerk, waarbij bandbreedte geen enkele issue is en compressie dan zowel op de server alsook op de client tijd in beslag neemt, die dus onnodig is.

Dat klopt, alles draait hier intern en het accent moet echt liggen op een snelle afhandeling bij de client.

Op dit moment lopen de eerste tests waarbij de inderdaad gebruik maken van xmlHTTP, in combinatie met (toch wel) XML. De resultaten zijn op het eerste gezicht goed, de informatie komt nu veel sneller op het scherm. Rest nu nog de taak om met goede scripting de informatie te laten zien. Daar had ik nog een vraag over

Klopt het dat ik voor dit soort dingen ivm snelheid het beste innerHTML kan gebruiken (PierreAronnax in "[javascript] Elementen toevoegen aan DOM...")? Ik lees hier op GoT daar niet altijd zulke goede reacties over compatibiliteit, maar aangezien het om een interne applicatie gaat en alle clients zeker de juiste versies gaat lijkt innerHTML het snelste? Of toch via DOM vanwege een reden die ik nu over het hoofd zie?

De informatie wordt nu in een tabel geladen (elke rij een nieuwe stap) en de bedoeling is om de extra info via een extra rij ertussen te plaatsen.

[wizzkizz]

Wat is nu de structuur van je tabel dan? In je openingspost gaf je aan dat je gebruik maakte van listings, dat heb je dus inmiddels veranderd naar tabellen?

Ik zou me voor kunnen stellen dat het gebruiken van listings sneller is. Bij tables zit je er mee dat als je een element invoegt dat breder is dan de kolom waar je in bezig bent, dat er dan dingen opnieuw gerenderd gaan worden. Bij lists afaik niet. Ook moet je minder elementen toevoegen (vgl. tr > td met li).

Maar er kunnen allerlei andere dingen meespelen natuurlijk. Wat ik in jouw geval zou doen, is allebei proberen en door middel van een timer bepalen wat (gemiddeld genomen) het snelste is. Dan kun je zo zien wat voor jouw specifieke situatie beter is. En timen kan afaik op milliseconden nauwkeurig, dus daar moet je een heel eind mee kunnen komen denk ik.

edit:
vergeet niet dat ook binnen jouw bedrijf de browsers een keer geupgrade gaan worden. Als je dan zoveel mogelijk via standaarden/nette manieren (in dit geval DOM) werkt, is de kans het grootst dat het zonder problemen blijft werken.

[ Voor 12% gewijzigd door wizzkizz op 03-02-2007 10:33 ]

[japaveh]

wizzkizz schreef op zaterdag 03 februari 2007 @ 10:31:
Wat is nu de structuur van je tabel dan? In je openingspost gaf je aan dat je gebruik maakte van listings, dat heb je dus inmiddels veranderd naar tabellen?

Ik ben inmiddels teruggegaan naar tabellen vanwege opmaakredenen. Er staat relatief veel informatie per stap op het scherm en ik wilde die graag recht onder elkaar uitgelijnd krijgen. Een rij ziet er ongeveer zou uit

[]	+	a	b	c	d	27 jan 2007	27 jan 2008	japaveh	Acetone Clean	Wetbench	nogwat editkopjes ed
[]	+		b		d	27 jan 2007	27 jan 2008	japaveh	Silver Depostion	CR	nogwat editkopjes ed
[]	+	a		c	d	27 jan 2007	27 jan 2008	japaveh	HF -dip	Wetbench	nogwat editkopjes ed

Dit is met tabellen eenmaal eenvoudiger dan met <li> elementen.

Ik zou me voor kunnen stellen dat het gebruiken van listings sneller is. Bij tables zit je er mee dat als je een element invoegt dat breder is dan de kolom waar je in bezig bent, dat er dan dingen opnieuw gerenderd gaan worden. Bij lists afaik niet. Ook moet je minder elementen toevoegen (vgl. tr > td met li).

Dat had ik inderdaad al gemerkt ja, ook wordt de lijst sneller opgebouwd dan de tabel dus ik ga waarschijnlijk wel terug naar een lijst. Ik werk met templates dus ik kan beide gevallen heel simpel met elkaar vergelijken.

Maar er kunnen allerlei andere dingen meespelen natuurlijk. Wat ik in jouw geval zou doen, is allebei proberen en door middel van een timer bepalen wat (gemiddeld genomen) het snelste is. Dan kun je zo zien wat voor jouw specifieke situatie beter is. En timen kan afaik op milliseconden nauwkeurig, dus daar moet je een heel eind mee kunnen komen denk ik.

edit:
vergeet niet dat ook binnen jouw bedrijf de browsers een keer geupgrade gaan worden. Als je dan zoveel mogelijk via standaarden/nette manieren (in dit geval DOM) werkt, is de kans het grootst dat het zonder problemen blijft werken.

Dat klopt. Ik ga maar eens een timer inbouwen om te kijken wat het snelste werkt.

Ik wil overigens iedereen alvast bedanken voor de input die ik tot zover gekregen heb!

[mjax]

Of gebruik fixed-width CSS voor je table, dan kan het renderen al tijdens het laden van de pagina beinnen.

[Verwijderd]

mijn voorkeur zou ook uitgaan om met ajax alles tot 1 mooie pagina te maken. maar omdat de informatie zeer groot en omvangrijk is kan dit het erg complex en traag maken. vandaar dat iframes dan weer beter zijn omdat je dan de pagina opsplitst zonder dat het er erg lelijk uitgaat zien ofzo.

innerHTML lijkt mij wel de juistje manier. gewoon voor elke plek alvast een lege div plaatsen en dan vullen per request.

een timer inbouwen is denk ik een goed idee. dan kun je ook eens gewoon wat testen en kijken wat het beste werkt. zorg wel dat deze optioneel is zodat je em in je productie versie kunt uitschakelen.