PHP·pub - Programming With Attitude - and beer

[Ernie]

Hvorfor må den være i ren PHP + HTML, da? Det fører bare med seg en MYE lengre sidelastingstid for brukere med trege linjer, samt at båndbredden blir enorm. Mye bedre å gi brukere med JS en skikkelig AJAX-basert progressbar, og andre brukere får pent vente til scriptet kjører ferdig. Ren PHP+HTML har bare for mange ulemper til at jeg ville giddet å bruke det.

7186321[/snapback]

Vel, det MÅ ikke være det. Det er bare jeg som ville se om det faktisk går. Fant et eksempel som angivelig skulle fungere, men gjorde ikke det. Etter litt modifikasjon har vi det over. At det er lastkrevende klarer jeg ikke helt se. Etter mine beregninger er det 70 byte som skrives ut. Uannsett kommer header om du bruker JS så det er ikke så krevnde på båndbredden heller

[Peter]

Hvorfor må den være i ren PHP + HTML, da? Det fører bare med seg en MYE lengre sidelastingstid for brukere med trege linjer, samt at båndbredden blir enorm. Mye bedre å gi brukere med JS en skikkelig AJAX-basert progressbar, og andre brukere får pent vente til scriptet kjører ferdig. Ren PHP+HTML har bare for mange ulemper til at jeg ville giddet å bruke det.

7186321[/snapback]

Kan du vise hvordan du har gjort dette?

Dessuten er jeg usikker på hvor stor forsinkelse du får.

Serveren jobber jo hardt som fy med oppgaven, og må i tillegg spytte ut litt html, men for klienten er dette faktisk en fordel i de fleste tilfeller, for brukeren får tilbakemelding på at noe skjer.

[Ernie]

Funket i Opera 9.02 på ubuntu edgy også.

Skal du gi ut koden?

Folk som er allergisk mot div-suppe burde kanskje holde seg unna.

Jeg tenkte på noe lignende, men istendenfor å skrive ut mange divs, så heller skrive ut et kall til en javascript-funksjon som endret størrelsen på baren.

På en måte kanskje mer portabelt, på en annen måte ikke.

Rimelig ufint på begge måter, men det er ikke så lett å åpne på andre måter.

7186266[/snapback]

Nei, hvor pent det er kan jo diskuteres. Derimot er det kjekt hvis man skal kjøre krevende operasjoner. I stedet for å vise en blank skjerm kan man vise fremgang noe som gjør at brukeren er mer tolmodig.

 

7186356[/snapback]

 

Bedre å vise grafikk som sier "loading ... ... ..." enn å gjøre operasjonen enda tregere fordi serveren driver med konstant output til en progressbar.

7186436[/snapback]

Nei, det å skrive ut "loading please wait" o.l er jo like nyttig som en blank skjerm. Brukeren veit jo selvsagt at noe lastes og tar tid. Derimot veit han/hun ikke hvor langt proessen er kommet, og det er jo det som faktisk er interessant.

[jorgis]

Hvorfor må den være i ren PHP + HTML, da? Det fører bare med seg en MYE lengre sidelastingstid for brukere med trege linjer, samt at båndbredden blir enorm. Mye bedre å gi brukere med JS en skikkelig AJAX-basert progressbar, og andre brukere får pent vente til scriptet kjører ferdig. Ren PHP+HTML har bare for mange ulemper til at jeg ville giddet å bruke det.

7186321[/snapback]

Vel, det MÅ ikke være det. Det er bare jeg som ville se om det faktisk går. Fant et eksempel som angivelig skulle fungere, men gjorde ikke det. Etter litt modifikasjon har vi det over. At det er lastkrevende klarer jeg ikke helt se. Etter mine beregninger er det 70 byte som skrives ut. Uannsett kommer header om du bruker JS så det er ikke så krevnde på båndbredden heller

7186461[/snapback]

 

Mine beregninger (wc --bytes) sier at 1500 bytes skrives ut i tillegg til selve siden.

 

Dessuten, om du bare skal outputte en liten progressbar, er det mye enklere å gjøre det fra klientens side. Om de har JS tilgjengelig, kan en bruke AJAX til å kalle et kjapt script fra serveren, noe som vil spawne en ny prosess/tråd til å håndtere oppdateringen av progressbaren, fremfor å bruke tid i det scriptet som driver den tunge beregningen el.l. Multi-tasking har en tendens til å være vanskelig å igangsette fra serversiden (bl.a. siden PHP på windows ikke støtter fork()).

 

For brukere uten JS er det jo bare å slenge ut en tekst som sier "please wait..." eller noe annet som kan tilfredstille utålmodigheten til folk.

[Peter]

Den må jo faktisk vite hvor mye den skal putte ut av progressbaren.

[jorgis]

Den må jo faktisk vite hvor mye den skal putte ut av progressbaren.

7186591[/snapback]

 

Avhengig av oppgave bør ikke dette være et stort problem. Er det snakk om uploads bør vel PHP-script kunne inspisere resultatet til andre script, og om det er downloads bør JSen selv kunne finne dette ut. Når det gjelder lange, CPU-intensive oppgaver blir det nok litt vanskeligere, men her har en pcntl_signal() og lignende funksjoner, men igjen er en tilbake på at windows ikke godtar dette.

 

 

Alternativt kan jo faktisk samme script bli spurt om progress av AJAX, og i stedet for å måtte outputte en div-tag kan det holde med å returnere bare prosentandelen, så står JS for selve rendringen og prosesseringen av grafen. Kan gjøres enten via vanlig output fra script (altså en mer fancy versjon av Ernie sitt script), eller via sockets/POST/GET-requests.

 

Det er i hvert fall mulig å lage en versjon som kan forbedre Ernie sin progressbar med følgende forbedringer:

 

1. Kan startes etter siden er ferdig lastet.

2. Kan minimere båndbredden til det absolutte minimum

3. Kan multitaske for å forhindre overhead eller forlengelse av oppgavens varighet.

 

 

EDIT: Typo.

Endret 30. oktober 2006 av jorgis

[Ernie]

jorgis: Siden du snakker så varmt om JS + Ajax her nå. Hvordan skulle det har vært implementert med JS? Etter mine beregninger må man uannsett ha en tilkobling hvor man spytter ut noe med jevne mellomrom, og det er jo akkurat det samme som det jeg gjør bare uten JS.

[Peter]

Jeg er helt enig i at alt det du sier høres bedre ut, men jeg vil gjerne se det i kode.

En klar fordel dersom dette er mulig er jo at du kan spytte ut hele siden, så ikke sider "stopper" ved progressbaren, flushe, og så gjøre den tunge oppgaven. Så kan AJAX probe ett eller annet for å vite hvor mye den skal vise. Men jeg ser bare ikke helt hvordan dette skal kunne foregå.

Endret 30. oktober 2006 av Nazgul

[jorgis]

Etter mine beregninger må man uannsett ha en tilkobling hvor man spytter ut noe med jevne mellomrom, og det er jo akkurat det samme som det jeg gjør bare uten JS.

7186706[/snapback]

 

Nei, av flere (overnevnte) grunner:

 

Med JS kan brukeren på eget intiativ starte oppgaven, og den kan startes _etter_ at siden er ferdig lastet. Progressbaren kan dermed tegnes hvor som helst på siden, uten å måtte vente med output av f.eks. footer til _etter_ at progressbaren er ferdig lastet.

 

Du kan minimisere mengden overført data. Istedenfor å overføre "<div class="bar" style="width: 159px"></div> <div class="per">58%</div>" ved hver oppdatering, kan den bare outputte "58", og så kan JSet ta seg av tegningen av grafen (manipulering av DOM/stil-attributter).

 

 

Nazgul:

Et eksempel på hvordan oppgaven kan startes av bruker, er jo å la en onClick-event på en link el.l. trigge en HTTP-request til server, som i sin tur starter PHP-scriptet. Alternativt kan en onLoad-event trigge det, om du ikke ønsker at bruker skal starte prosessen selv.

 

For brukere uten JS, kan muligens en link til en iframe erstatte det, eller bare outputte et bilde med en fin "loading..."-animasjon. Selv om Live Mail bruker nærmere et halvt minutt å laste, gir de meg ikke en progressbar, så det er ikke absolutt nødvendig uansett JS eller ikke.

[Ernie]

Etter mine beregninger må man uannsett ha en tilkobling hvor man spytter ut noe med jevne mellomrom, og det er jo akkurat det samme som det jeg gjør bare uten JS.

7186706[/snapback]

 

Nei, av flere (overnevnte) grunner:

 

Med JS kan brukeren på eget intiativ starte oppgaven, og den kan startes _etter_ at siden er ferdig lastet. Progressbaren kan dermed tegnes hvor som helst på siden, uten å måtte vente med output av f.eks. footer til _etter_ at progressbaren er ferdig lastet.

 

Du kan minimisere mengden overført data. Istedenfor å overføre "<div class="bar" style="width: 159px"></div> <div class="per">58%</div>" ved hver oppdatering, kan den bare outputte "58", og så kan JSet ta seg av tegningen av grafen (manipulering av DOM/stil-attributter).

7186888[/snapback]

Ja, men du må uannsett sende data. Tok en måling her. Absolutt alt sammen tok 4138byte. Mulig det bare er meg, men 4kB er ikke mye å skrike over

 

Uannsett, skal du bruke Ajax til det her kan jeg med en gang si du kommer til å bruke betydelig mye større mengde båndbredde da hver request vil være på drøyt 500byte.

 

Redigering: Hvis du skulle realisere akkurat det samme som meg med Ajax vil bruke drøyt ca 6kB inn og ca10kB ut. Jeg bruker ca 4kB inn og 0,5kB ut. Så Ajax funker dårlig til det her hvis du skal forsøke å minimere båndbredden.

Endret 30. oktober 2006 av Ernie

[jorgis]

Ja, men du må uannsett sende data. Tok en måling her. Absolutt alt sammen tok 4138byte. Mulig det bare er meg, men 4kB er ikke mye å skrike over

 

Uannsett, skal du bruke Ajax til det her kan jeg med en gang si du kommer til å bruke betydelig mye større mengde båndbredde da hver request vil være på drøyt 500byte.

 

Redigering: Hvis du skulle realisere akkurat det samme som meg med Ajax vil bruke drøyt ca 6kB inn og ca10kB ut. Jeg bruker ca 4kB inn og 0,5kB ut. Så Ajax funker dårlig til det her hvis du skal forsøke å minimere båndbredden.

7186997[/snapback]

 

Hvor får du tallene fra? Og hvem sier at en må gjøre en dedikert HTTP-request for hver oppdatering? En kan jo bruke output-buffering slik du gjør i ditt eksempel, selv om en bruker JS-versjonen. Da kan en klare å redusere output til mellom tre og fire byte per oppdatering av progress-baren (en oppdatering kan da bestå av "|44|" ved 44%, eller "|9|" ved 9%). Med 100 oppdateringer (en for hver %), vil en da få 300-400kB (pluss første request, som kan være HTTP-request med headere, totalt 100-200kB). 400-500kB er langt ifra 16kB, og om en skipper HTTP totalt, kan en redusere det ytterligere.

[Ernie]

Ja, men du må uannsett sende data. Tok en måling her. Absolutt alt sammen tok 4138byte. Mulig det bare er meg, men 4kB er ikke mye å skrike over

 

Uannsett, skal du bruke Ajax til det her kan jeg med en gang si du kommer til å bruke betydelig mye større mengde båndbredde da hver request vil være på drøyt 500byte.

 

Redigering: Hvis du skulle realisere akkurat det samme som meg med Ajax vil bruke drøyt ca 6kB inn og ca10kB ut. Jeg bruker ca 4kB inn og 0,5kB ut. Så Ajax funker dårlig til det her hvis du skal forsøke å minimere båndbredden.

7186997[/snapback]

 

Hvor får du tallene fra? Og hvem sier at en må gjøre en dedikert HTTP-request for hver oppdatering? En kan jo bruke output-buffering slik du gjør i ditt eksempel, selv om en bruker JS-versjonen. Da kan en klare å redusere output til mellom tre og fire byte per oppdatering av progress-baren (en oppdatering kan da bestå av "|44|" ved 44%, eller "|9|" ved 9%). Med 100 oppdateringer (en for hver %), vil en da få 300-400kB (pluss første request, som kan være HTTP-request med headere, totalt 100-200kB). 400-500kB er langt ifra 16kB, og om en skipper HTTP totalt, kan en redusere det ytterligere.

7187558[/snapback]

Tallene er fra ethereal siden jeg ikke orket å regne ut for alt sammen selv. Skal man sende en pakke som fortsetter en annen blir det ca 54byte + data. Setter man opp 100 oppdateringer så blir det dog aldir mer enn 12,7kB for mitt tilfelle. Skal man bruke js som ikke alle har blir det 5,8kB. Med andre ord ikke store datamengdene.

[dabear]

PHP 5.2 Lansert!

 

http://norskwebforum.no/viewtopic.php?p=218150#218150

 

Noen av nyhetene tar jeg svært godt imot, spesielt integrasjonen av json og input filters.

New memory manager for the Zend Engine with improved performance and a more accurate memory usage tracking.

Input filtering extension was added and enabled by default.

JSON extension was added and enabled by default.

ZIP extension for creating and editing zip files was introduced.

Hooks for tracking file upload progress were introduced.

Introduced E_RECOVERABLE_ERROR error mode.

Introduced DateTime and DateTimeZone objects with methods to manipulate date/time information.

Upgraded bundled SQLite, PCRE libraries.

Upgraded OpenSSL, MySQL and PostgreSQL client libraries for Windows installations.

Many performance improvements.

Over 200 bug fixes.

 

http://www.php.net/releases/5_2_0.php

http://www.php.net/UPDATE_5_2.txt

[jorgis]

Yay, men når vil vi få se den i bruk hos webhoster? Jeg sliter med Servetheworld, som kjører PHP 4.4.4 fremdeles...

[Ernie]

Tror nok dessverre vi fortsatt kommer til å slite med sneglehoster. Det kommer nok av at PHP5 ikke er så mye etterspurt som det burde. De som lager script er gjerne såpass "dumme" at de støtter PHP4 også selv om man virkelig burde bare støtte PHP5. Det resulterer i at det ikke er nok press for å få en overgang.

[Peter]

Hooks for tracking file upload progress were introduced.

Så utrolig fett!

[allyse]

Avventer litt med å oppgradere, men det kommer seg. Ikke glemme at PHP6 har "beta"-release trolig neste måned

 

Nå er det på høyst tide php4 dør

Endret 3. november 2006 av allyse

[jorgis]

Nå er det på høyst tide php4 dør

7209795[/snapback]

 

Jupp, men tror vi får se webhoster holde fast i PHP4 til lenge etter PHP6 blir sluppet.

Endret 3. november 2006 av jorgis

[allyse]

Jupp, men tror vi får se webhoster holde fast i PHP4 til lenge etter PHP6 blir sluppet.

7209803[/snapback]

 

Ja. Da jeg lette etter PHP5-hoster for rundt et år siden var det nesten en umulig oppgave. Nå har flere og flere støtte for PHP5.

 

Kan ikke se på et punkt PHP4 har en fordel over PHP5. La oss følge utviklingen.

(Progger nå selv hovedsaklig for PHP5, og på store ting støtter jeg i utgangspunktet ikke PHP4 lengre, det er utdatert imo)

 

Jeg forstår da at PHP4 har holdt så lenge mtp. f.eks klasseendringene mellom php4 og php5, samt at register globals var en periode på i php4. Folk er for late til å endre scriptene sine.

[jorgis]

Jeg forstår da at PHP4 har holdt så lenge mtp. f.eks klasseendringene mellom php4 og php5, samt at register globals var en periode på i php4. Folk er for late til å endre scriptene sine.

7209875[/snapback]

 

Akkurat. Folk slenger opp et gammelt script eller CMS på webhotellet sitt og tør ikke/kan ikke oppgradere til en versjon som funker i PHP5. Webhosten tør da ikke tvinge folk over på PHP5, da det blir månelyst om 50 sider plutselig ikke lenger virker slik de gjorde. start.no fikk f.eks. mye problemer med overgangen til avslått register_global.

 

Det jeg ba STW om, var at de satte opp en eller to servere til å kjøre PHP5, og så kunne kunder som ønsket det bli flyttet over, men de nektet. De gav inntrykk av å være bundet til serveradmin-systemet deres, og sa at de ikke oppgraderte før det kom i ny versjon.