Bekijk Volledige Versie : PHP output probleem
Ik ben bezig met een script waarin op een site die bestaat uit vele tabellen etc, er op een gegeven moment een button van een formulier wordt weergegeven. De bedoeling is dat op t moment dat de gebruiker op de button clickt t script gaat draaien etc. So far so good, das niet zo moeilijk.
Maar nu het probleem:
Als er geklikt is op de button, komt in de volgende pagina (of een refresh van de oude) de output van het script te staan. Dit zit in een tabel die weer genest is in andere tabellen etc. Probleem is dat dit script vrij lang de tijd nodig heeft om te draaien, en ik graag een loading bar of iets dergelijks en in ieder geval de footer etc alvast wil laten zien. Maar omdat het script dan nog bezig is, wordt de rest(zelfs niet de overige html codes in dezelfde tabel) van de pagina niet weergegeven. Even een schets:
<pagina & html>
<tabellen>
<tabel van oa het script>
<ander field>
<field van het script>
<footer en overige gedeelte van het script>
gaat nu het script lopen, wordt alleen
<pagina & html>
<tabellen>
laten zien tot het script draait, maar de bedoeling is juist dat eerst alles wordt laten zien, dus ook de footer, en pas dan, als het script klaar is, de output er als t ware tussen gepropt wordt.
Heeft iemand een idee hoe ik dit kan oplossen, en of er uberhaubt een mogelijkheid is?. De output van het script is oa een tabel met een plaatje en text uit verschillende variabeles. Ik zat te denken aan misschien iets met javascript oid, maar erg bekend ben ik hier niet mee en ik weet eigenlijk ook niet goed hoe ik mijn vraag in google zou kunnen formuleren.
V. Kleijnendorst
08/10/06, 11:13
Met Ajax kun je ervoor zorgen dat bijvoorbeeld een <div> gevuld wordt met de output van je script.
Een andere optie is om met flush() eerst output te geven.
Een simpele en doeltreffende oplossing is alsvolgt:
Laat op de pagina waar naar gepost wordt een regel printen als 'Even geduld a.u.b.' in een div die bijvoorbeeld het id 'message' heeft. Roep vervolgens in PHP de functie 'flush ()' aan, deze zorgt ervoor dat deze mededeling wordt weergegeven en de rest nog niet. Laat nu het script uitvoeren en zodra dit voltooid is laat je het volgende Javascript uitvoeren: document.getElementById('message').style.display = 'none';. Dit laatste zorgt ervoor dat de melding verdwijnt, je zou eventueel ook met document.getElementById('text').innerHTML = 'Melding', de betreffende tekst kunnen aanpassen.
Succes ermee :)
Met Ajax kun je ervoor zorgen dat bijvoorbeeld een <div> gevuld wordt met de output van je script.
Een andere optie is om met flush() eerst output te geven.
heeft geen zin als je tabellen gebruikt.
bedankt voor de reacties, zoals mikey al zegt flush() heeft geen nut omdat ik tabellen gebruik en dus het niet de afsluitende codes laat zien als ik flush, en dus nog steeds geen output krijg.
Ik had inderdaad al hetzelfde als alternatief in mijn hoofd robbinh, dat zal het waarschijnlijk dan maar worden, want als ik het goed begrijp is het dus onmogelijk om bijvoorbeeld eerst de pagina te schrijven en dan misschien met bijvoorbeeld javascript later pas de output van het script erin te zetten?
Zoals ik al zei kan je flush () aanroepen voordat de tabellen gegenereerd worden, dan maakt dat niet uit en kan je de resultaten later prima laten weergeven.
Het is uiteraard ook mogelijk om via javascript de output te tonen, dit geheel volgens de AJAX-hype. Meer info hoe je dit soort zaken kan opzetten vind je hier: http://www.alistapart.com/articles/gettingstartedwithajax/.
Je zou ook een frame of iframe kunnen gebruiken.
Persoonlijk denk ik dat je beter je script kunt optimaliseren, zodat het sneller laadt.
Je zou ook een frame of iframe kunnen gebruiken.
Persoonlijk denk ik dat je beter je script kunt optimaliseren, zodat het sneller laadt.
Een frame of iframe is juist een uiterst antieke oplossing wat je m.i. niet meer dient te gebruiken. Daarbij is optimaliseren niet altijd mogelijk, denk aan een domeincontrole, zoiets kost nou eenmaal een hoop tijd.
een uiterst antieke oplossing wat je m.i. niet meer dient te gebruiken
Misschien kun je ook wat argumenten aandragen voor deze onzinnige stelling? Heb je wel eens op Marktplaats.nl gekeken?
Een frame of iframe is juist een uiterst antieke oplossing wat je m.i. niet meer dient te gebruiken. Daarbij is optimaliseren niet altijd mogelijk, denk aan een domeincontrole, zoiets kost nou eenmaal een hoop tijd.
Een domein controlle kun je in een halve seconde doen. Mits de server online is. Als je dat niet eerst controleert kan het inderdaad lang duren.
haha nouja het betreft hier het starten van gameservers, dus tja dat duurt altijd wel even hoe je het ook went of keert, bij mij op de server niet erg lang, maar toch is het vervelend als in die paar seconden alleen de header te zien is. Ik heb op dit moment de oplossing gemaakt (misschien wat omslachtig) door een div te maken die vrijwel een identieke kopie is in html van wat je ziet van de site, maar dan met alleen html en dus alleen een loading bar op de juiste plaats, wanneer het script geladen is, wordt dit vervangen door het werkelijke script + output, nog even tweaken, maar lijkt geweldig te werken. overigens kon flush echt niet in mijn geval en iframes waren niet de oplossing omdat het een formulier is waarmee het script is gestart en je dan niet de variabelen kan laden.
Misschien kun je ook wat argumenten aandragen voor deze onzinnige stelling? Heb je wel eens op Marktplaats.nl gekeken?
Marktplaats is nou niet bepaald het schoolvoorbeeld van semantieke correctheid en navolging van webstandaarden. Dat een grote en bekende website een techniek gebruikt wil natuurlijk niet zeggen dat dit een goede oplossing is. Telegraaf.nl voldoet ook niet bepaald aan de webstandaarden, is dit dan per se de manier waarop het hoort?
Anyway, dit is niet relevant, want het moge duidelijk zijn waarom frames geen goede oplossing zijn. Zo is het slecht toegankelijk voor tekstbrowsers of browsers voor invaliden en mobiele apparaten, is het uiterst slecht spiderbaar voor zoekmachines en daarnaast zorgt het ook nog eens voor een overvloed aan scrollbalken. Een andere reden tot slot om niet met frames te werken is dat je op basis van xHTML en CSS hetzelfde effect kan genereren dat de bovengenoemde nadelen niet heeft.
Dat een techniek niet voldoet aan webstandaarden maakt die techniek nog niet antiek. Vraag je ook eens af waarom een site zoals Marktplaats die frames nog gebruikt: juist om de laadtijd te beperken. En dat is precies wat de TS ook wil.
zoals ik al zei kan ik hier geen iframe gebruiken (normale al helemaal niet) ik heb wel ns vaker met frames gewerkt, en op een paar nadelen na is het niet slecht om te gebruiken (zolang je bijvoorbeeld niet verwacht dat je menus etc in tact blijven als iemand de pagina via google vind ;) ) hier kon het helaas dus niet omdat als ik het formulier de actie naar het frame zou laten sturen, wat nodig zou zijn, alleen het frame zou zien, en niet de rest, of als ik het naar de normale pagina zou sturen het dus geen nut voor het script zou hebben in het frame ;), nu heb ik het dus opgelost voor een groot deel met javascript, alleen heb ik nog een probleem waar ik momenteel aan werk: de output in de <div> wordt in eerste instantie normaal getoond, maar als het script klaar is en de output vervangen wordt door javascript zit er plotseling een break onder, zeg maar een gat tussen de content die javascript vervangt en de rest van de site, terwijl dit niet het geval is als ik handmatig de content vervang met hetzelfde als wanneer javascript dit doet, weet iemand misschien waarom?
Bleek te liggen aan de code die origineel in de div stond, vreemd genoeg geeft dit pas resultaat als het vervangen wordt, het ging om een <form> tag.
Dat een techniek niet voldoet aan webstandaarden maakt die techniek nog niet antiek. Vraag je ook eens af waarom een site zoals Marktplaats die frames nog gebruikt: juist om de laadtijd te beperken. En dat is precies wat de TS ook wil.
toen ik de laatste keer keek draaide marktplaats.nl nog op PHP3 (niet eens zo heel lang geleden). Wie draait er hier nog meer op PHP3 als je die site modern wenst te noemen.
Ho, ik heb het woord modern niet gebruikt. Ik ben alleen van mening dat je best mag terugvallen op een 'oude' techniek als dat de beste oplossing voor een probleem blijkt te zijn, en in het geval van Marktplaats, dat je een oude techniek mag blijven gebruiken als er geen reden is om deze te vervangen.
Dat ben ik niet met je eens, als de beperking van de laadtijd de reden is om frames te gebruiken kan je beter overstappen op een op webstandaarden gebaseerde website. Dat verkleint de paginagrootte namelijk aanzienlijk doordat er minder code in de broncode staat en de scripts en stylesheets worden gecached. Frames zijn dan dus niet meer nodig voor dit argument en dan kan je ook nog eens profiteren van alle andere voordelen van webstandaarden.
Paginagrootte is een kul-argument tegen frames. De extra kB die je hebt omdat je één keer een extra html/head/body moet laden is te verwaarlozen. En het gebruik van frames sluit het gebruik van stylesheets niet uit, en ook bij frames worden pagina's gecached. Sterker nog, bij frames wordt minder code gecached, dus pagina's zijn sneller!
Ik ben het met je eens dat je zoveel mogelijk de standaarden moet volgen, maar dat betekent nog niet dat je geen frames meer mag gebruiken. Er is geen opperwezen dat je een boete geeft als je frames gebruikt.
In het geval van de TS zou een iframe een prima oplossing zijn, beter dan een oplossing met layers die pas op je scherm verschijnen zodra de hele pagina geladen is. Dat de TS niet weet dat je ook naar een iframe kan posten, soit...
Paginagrootte is een kul-argument tegen frames. De extra kB die je hebt omdat je één keer een extra html/head/body moet laden is te verwaarlozen. En het gebruik van frames sluit het gebruik van stylesheets niet uit, en ook bij frames worden pagina's gecached. Sterker nog, bij frames wordt minder code gecached, dus pagina's zijn sneller!
Ik ben het met je eens dat je zoveel mogelijk de standaarden moet volgen, maar dat betekent nog niet dat je geen frames meer mag gebruiken. Er is geen opperwezen dat je een boete geeft als je frames gebruikt.
In het geval van de TS zou een iframe een prima oplossing zijn, beter dan een oplossing met layers die pas op je scherm verschijnen zodra de hele pagina geladen is. Dat de TS niet weet dat je ook naar een iframe kan posten, soit...
Paginagrootte is juist geen kulargument. Jij geeft aan dat een snelle laadtijd de reden is dat bij Marktplaats frames worden gebruikt, op mijn beurt geef ik aan dat dit ook te bewerkstelligen is door webstandaarden te hanteren. Dan lijkt het me voor de hand liggend dat dit een betere oplossing is.
Maar goed, waarschijnlijk kan ik je hier niet van overtuigen, laat ik het om het af te sluiten daarom maar zo zeggen: als ik de webdeveloper van Marktplaats was geweest, dan had ik niet met frames gewerkt :)