Back-end progress balk in DHTML - Softwareontwikkeling

woensdag 7 januari 2004 23:17

Acties:

Topicstarter

Voor een project waarin een back-end programma wordt gekoppeld aan een (D)HTML interface ben ik aan het experimenteren met een 'progress' bar die aangeeft waarmee het back-end programma bezig is.

Je kan zo'n DHTML programma in actie zien op http://elcheapo.nl. Het werkt door na de html + javascript code nog een aantal javascript functies 'na' te sturen.

Zo:

HTML:

<html>
  <head>
    <script type="text/javascript">
      function doeIets() {
        ..
      }
      function doeIetsAnders() {
        ..
      }
    </script>
  <body>
    <bla>
  </body>
</html>

... wacht even ...

<script type="text/javascript">
  doeIets();
</script>

... wacht even ...

<script type="text/javascript">
  doeIetsAnders();
</script>

Nu blijkt dat dit niet goed werkt in Mozilla (ik heb 1.5). Mozilla rendert niet voordat de hele pagina geladen is. En dan worden doeIets() en doeIetsAnders() heel snel achter elkaar uitgevoerd.

Dit vond ik in http://www.mozilla.org/docs/url_load.html:

The parser typically gets data from the stream in 8kb blocks and parses these blocks, block by block. After every parsed block it passes the parsed data as nsIParserNodes to the ContentSink unless the parser has been temporarily blocked, in wich case it waits until it gets unblocked before parsing the cached data it has receieved while being blocked.

Het lijkt er dus op dat Mozilla wacht totdat hij 8 KiB aan data heeft voordat er iets gerenderd gaat worden.

Ik heb een voorbeeld pagina op http://rotzorg.org/~sgr/dynamicstatus/. Dit is een perl script dat een pagina op het scherm zet en dan na 2 seconden de kleur van de titel rood moet maken, en daarna na 2 seconden de kleur blauw. Omdat de inhoud van de html nogal groot is toont Mozilla de 'gewone' zwarte versie van de titel. Even later wordt die blauw, want Mozilla wacht totdat rood + blauw geladen zijn.

Het zou een beetje vreemd zijn om in de wachtijd ook 8 KiB aan data te gaan meesturen om Mozilla te laten renderen; weten jullie misschien een beter idee?

-- edit
Oh, ik weet niet hoe het is in Internet Explorer. (ik zie namelijk mensen met zo'n browser in mijn logs.) Kan iemand feedback geven?

[ Voor 13% gewijzigd door Sendy op 07-01-2004 23:23 ]

woensdag 7 januari 2004 23:24

Acties:

André

Analytics dude

Sendy schreef op 07 januari 2004 @ 23:17:

..snap..

Wat ik wel eens gedaan heb is de voortgang bijhouden in de window.status. Die word direct bijgewerkt.

[ Voor 82% gewijzigd door André op 07-01-2004 23:24 ]

woensdag 7 januari 2004 23:35

Acties:

Sendy

Topicstarter

André >
Ik kan het me niet voorstellen dat iets in de window.status schrijven zou helpen; maar misschien begrijp ik je niet helemaal. Zo'n buffer als Mozilla schijnt te gebruiken zal niet eerder uitgelezen worden als 'window.status' erin voorkomt. Kan je misschien verduidelijken?

woensdag 7 januari 2004 23:39

Acties:

Erkens

Fotograaf

misschien kan je hier wat mee?
http://www.pushlets.com/

woensdag 7 januari 2004 23:40

Acties:

André

Analytics dude

Sendy schreef op 07 januari 2004 @ 23:35:
André >
Ik kan het me niet voorstellen dat iets in de window.status schrijven zou helpen; maar misschien begrijp ik je niet helemaal. Zo'n buffer als Mozilla schijnt te gebruiken zal niet eerder uitgelezen worden als 'window.status' erin voorkomt. Kan je misschien verduidelijken?

Hmm, ik zat even verkeerd te denken. Nu begrijp ik wat je bedoeld.

woensdag 7 januari 2004 23:53

Acties:

Sendy

Topicstarter

Erkens >
oh ja, het zou inderdaad kunnen zijn dat het cgi (perl) script buffert. Jammer genoeg lijkt er geen flush() functie te zijn in perl

Dat wordt dus nog even zoeken.

-- edit
En ja hoor, dat was het. Dit was dus eigenlijk een Programming & Webscripting vraag. Een $| = 1, net voor de code die de javascript 'na' functies uitvoert doet wonderen.

[ Voor 36% gewijzigd door Sendy op 07-01-2004 23:57 ]

donderdag 8 januari 2004 00:17

Acties:

Gem1e

mn pa stond hier nog ingelogd

[ Voor 93% gewijzigd door Gem1e op 08-01-2004 00:17 ]

donderdag 8 januari 2004 00:18

Acties:

SchizoDuckie

Kwaak

Ik ben hier een tijdje geleden ook mee bezig geweest, en wat ik gedaan heb is uiteindelijk heel simpel:

Aangezien gifjes en andere animaties stopgezet wroden tijdens het laden van een nieuwe pagina, heb ik zelf een soort van anim scriptje gebouwd, dat gewoon een plaatje elke zoveel milliseconden wisselt. Die staat in een alwaysontop divje, waarin er wordt gezegd dat je even geduld moet hebben tijdens het laden van de pagina

demo te zien @ http://www.schizofreend.nl/lokalenplanner/

Stop uploading passwords to Github!

donderdag 8 januari 2004 09:20

Acties:

creative8500

freedom.

Papa Eend: Er is naturlijk een verschil tussen zeggen dat de data er nog niet is, en zeggen hoever een proces is gevorderd.

donderdag 8 januari 2004 09:52

Acties:

Bosmonster

*zucht*

Een hoop moeite en browserproblemen voor niks dus

Persoonlijk zou ik ook gaan voor een div met daarin de melding dat het systeem bezig is. Eventueel een 'oneindige' progressbar zoals Microsoft die veel gebruikt tegenswoordig (soort KnightRider balkje

).

100x eenvoudiger en weet je zeker dat het werkt in alle browsers, ook in die nog uit gaan komen en oudere versies. Want je kunt er nu eenmaal nooit vanuit gaan hoe een browser omgaat met de data die die binnenkrijgt. Hier kan zelfs een netwerk (proxy/router) nog wel roet in het eten gooien zelfs. Wil je daar echt afhankelijk van zijn voor een progressbalkje?

Ik iig niet

(ander voordeel.. je zit niet met die vreselijk irritante pagina-overgangen zoals elcheapo die heeft. Die redirect en daarmee flitsen er 2 pagina's voorbij als ik op zoeken druk, want die hele progressbar duurt hier ongeveer 0,5 seconde. Dat herladen van die pagina's kost denk ik nog meer tijd dan de hele zoekactie

).

[ Voor 21% gewijzigd door Bosmonster op 08-01-2004 09:54 ]

donderdag 8 januari 2004 10:03

Acties:

André

Analytics dude

Bosmonster schreef op 08 januari 2004 @ 09:52:
...knip...

Ugh. en zo zij het...

En wat betreft dat oneindige progressbarretje: dat is geen progressbar maar een busybar of iets dergelijks.

[ Voor 68% gewijzigd door André op 08-01-2004 10:04 ]

donderdag 8 januari 2004 10:58

Acties:

Sendy

Topicstarter

Bosmonster >
Bedankt voor je zorgen. Eigenlijk wil alleen mijn baas het (nou ja, het back-end programma kan zomaar een kwartiertje bezig zijn met rekenen dus een progress-balk is /wel/ fijn), dus zal ik jouw opmerkingen meenemen in het voorstel.

donderdag 8 januari 2004 10:59

Acties:

Bosmonster

*zucht*

Als je backend een kwartier bezig is is het uberhaupt niet verstandig om dit via een browser ta gaan benaderen lijkt me. Of ga je ook de script-timeouts e.d. nog omzeilen?

Misschien is het als het zolang duurt verstandiger om een commando uit te voeren op de server en dit proces af en toe een bestandje weg te laten schrijven. In je browser zou je dit dan iedere 10 seconden ofzo kunnen herladen.

[ Voor 41% gewijzigd door Bosmonster op 08-01-2004 11:00 ]

donderdag 8 januari 2004 11:18

Acties:

Sendy

Topicstarter

Bosmonster >
Script time-outs zijn inderdaad nog wel vervelend. (Vooral als we tussen de back-end en de browser nog een Apache Cocoon2 gaan plaatsen

) Zo'n tijdelijk bestand is waarschijnlijk nog wel te doen ook. 'k neem 't mee.

donderdag 8 januari 2004 16:14

Acties:

Bluestorm

Of je maakt een xml-rpc service waar je de voortgang op de server kan opvragen van een bepaalde actie... en die laat je je javascript dan steeds checken en weergeven... en als 't 100% is dan refresh je naar de resultaatpagina. (of die resultaten haal je ook met xml-rpc op ofzo)

Tenminste... dat [ denk / zie / weet ] ik... | Javascript obfuscator | foto's en video's uploaden