AJAX/PHP/MYSQL/HTML

[Verwijderd]

Een bestaande website welke ik enkele jaren geleden heb gebouwd ben ik aan het herschrijven en wil daar ook een stuk AJAX in verwerken. Nu ben ik al een eind gekomen maar loop tegen een vraag aan waar ik niet uitkom.

Gewenste situatie

De site is opgebouwd uit tables (html) en daarin wordt informatie gestopt welke d.m.v. queries uit de database wordt gehaald. Weinig bijzonders. Graag wil ik de HTML tables inclusief inhoud uit de database halen m.b.v. XMLHttpRequest.

Huidige situatie

Ik krijg de informatie uit de database weer terug incl. HTML tables. In principe werkt het dus. Wat ik graag wil weten is hoe ik het nu het beste kan aanpakken. Op dit moment heb ik het zo aangepakt:

verwerk.php

$BMW = mysql_query("SELECT * FROM Producten WHERE P_Soort = 'T' AND Merk LIKE '%BMW%'");
$BMW_Inhoud = mysql_num_rows($BMW);

print "<tr bgcolor=#D6D6D6>";
print "<td align=center>";
print "<a href=index.php?Actie=Producten_Overzicht&P_Soort=T&Merk=BMW&Categorie=0>";
print "BMW";
print "</a>";
print "</td>";
print "<td align=center>";
print $BMW_Inhoud;
print "</td>";
print "</tr>";

Vraag

Hoe kan ik de php pagina nu het beste opbouwen? Dus, laat ik de tabellen opmaken in php en teruggeven via XMLHttpRequest of laat ik puur de database-informatie teruggeven via XMLHttpRequest?

In dat laatste geval moet ik volgens mij de waarden in een array stoppen en die uitlezen in de index.php laten tonen in de table. Maar hoe doe ik dat?

[japaveh]

Eventjes een eerste vraag: Waarom wil je graag AJAX gebruiken? Ik zie het nut er niet zo van in hier namelijk.

[killercow]

Omdat je erg veel htm nodig hebt om een record toe te voegen is dit natuurlijk lastig, maar wat de goede richting in is:

Haal alleen je data op via ajax, en genereer aan de client-side dmv javascript DOM de nodige html structuur voor elk record, zou hou je je xml api netjes en clean (die geeft alleen data terug), en hou je de presenterende code (die in dit geval je html maakt) netjes in javascript.

Dat dit nu erg lastig is komt omdat je erg veel html nodig hebt. Mooier is als je je html zo minimaal mogelijk opzet en je styling weer in je stylesheets doet, deze worden automatisch meegenomen op nieuw gemaakte tr's en dit scheelt weet in het maken van javascript.

[djiwie]

Met japaveh eens, en verder kun je beide manieren gebruiken. Als je alleen de ruwe informatie met AJAX ophaalt zul je de opmaak en verdere presentatie door Javascript moeten laten regelen, laat je de opmaakt door PHP genereren (al dan niet door een functie/template of iets anders herbruikbaars) hoef je alleen maar de HTML-code door Javascript in te laten voegen.

[Verwijderd]

japaveh schreef op dinsdag 24 juni 2008 @ 14:10:
Eventjes een eerste vraag: Waarom wil je graag AJAX gebruiken? Ik zie het nut er niet zo van in hier namelijk.

Ik wil AJAX gebruiken om de site te versnellen en interactieve functionaliteit toe te voegen. Kan ik verder met bovenstaand stukje code dan weet ik voldoende om met de rest v.d. site verder te kunnen. Nu je dit weet, kun jij mij verder helpen Japaveh?

[japaveh]

Verwijderd schreef op dinsdag 24 juni 2008 @ 14:18:
[...]


Ik wil AJAX gebruiken om de site te versnellen en interactieve functionaliteit toe te voegen. Kan ik verder met bovenstaand stukje code dan weet ik voldoende om met de rest v.d. site verder te kunnen. Nu je dit weet, kun jij mij verder helpen Japaveh?

Ik weet niet of de site er wel zoveel sneller van wordt eigenlijk. uiteraard je kunt het geheel daardoor interactieve maken... Verder zou ik dan de manier van killercow gebruiken en een zo clean mogelijke datastroom gebruiken die je met DOM een mooie layout geeft.

[Verwijderd]

japaveh schreef op dinsdag 24 juni 2008 @ 14:20:
[...]

Ik weet niet of de site er wel zoveel sneller van wordt eigenlijk. uiteraard je kunt het geheel daardoor interactieve maken... Verder zou ik dan de manier van killercow gebruiken en een zo clean mogelijke datastroom gebruiken die je met DOM een mooie layout geeft.

Oké, beide dank. Ik ga op zoek naar informatie om het op de manier van killercow te verwezenlijken. Mocht ik nog vragen hebben dan zal ik ze stellen, dus graag nog ff geen slotje.

[Creepy]

offtopic:
Als je een oplossing hebt gaan topics niet op slot, alleen foute topics gaan op slot en zo fout is dit topic niet

[Verwijderd]

Creepy schreef op dinsdag 24 juni 2008 @ 15:00:

offtopic:
Als je een oplossing hebt gaan topics niet op slot, alleen foute topics gaan op slot en zo fout is dit topic niet

Heel fijn

[Verwijderd]

Om AJAX volledig tot z'n recht te laten komen moet de site natuurlijk worden gebouwd in Java-script. Maar aangezien ik daar (nog) niet zo goed in thuis bent dan zou ik het graag willen combineren met PHP. Wat ik daarvoor nog graag zou willen weten is óf, en zo 'ja' hoe ik de resultaten uit de XMLHTTPRequest kan teruggeven aan een php variabele of array? Dus niet de link leggen met een HTML DIV wat in veel tutorials wordt gebruikt.

[Creepy]

Eeh.. AJAX is een techniek om clientside (javascript) gegevens te laten uitwisselen met de server (waar o.a. php kan draaien). Als je PHP kant en klare pagina's laat teruggegeven zonder gebruikt te maken van javascript op de clientkant dan is het geen Ajax meer. Je hebt dan welk voor elke verandering op je pagina een complete reload nodig, en Ajax is er nu juist voor om alleen de data te laden die op dat moment nodig is om zo een volledige pagina reload te voorkomen.

[RM-rf]

Verwijderd schreef op woensdag 02 juli 2008 @ 08:45:
Om AJAX volledig tot z'n recht te laten komen moet de site natuurlijk worden gebouwd in Java-script. Maar aangezien ik daar (nog) niet zo goed in thuis bent dan zou ik het graag willen combineren met PHP. Wat ik daarvoor nog graag zou willen weten is óf, en zo 'ja' hoe ik de resultaten uit de XMLHTTPRequest kan teruggeven aan een php variabele of array? Dus niet de link leggen met een HTML DIV wat in veel tutorials wordt gebruikt.

met alle respect maar dat is complete onzin, een HTML site is niets anders dan dat, data gepresenteerd binnen HTML-datastructuren (tags) waarbij mogelijkde visuele presentatie via CSS geregeld wordt....

let hierbij op wat het verschil is tusen wat er op de client gebeurt (de presentatie van gegevens binnen HTML) en op de server (het versturen van gegevens, waarbij bv PHP een datastroom genereert)..
Javascript kan hooguit als 'intermediate' functioneren, bv doordat je mbhv de Ajax-techniek Javascript requests genereert van de client naar de server toe en deze weer gegevens uitleest en die 'on-the-fly' in pagina's verwerkt.

Zorg er eerst voor dat je die basis goed en correct begrijpt voordat je bepaalde voortijdse 'conclusies gaat maken en daarop een wensenpatroon baseert dat niet reeel is.
een van de dingen die je ook goed realiseeren moet is dat AJAX gebaseerd is op javascript en niet op PHP (anders had het wel APAX geheten het verschil: de tweede is het grootste, rijkste en succesvolste investeringsconcern ter wereld en de eerste een tweederangs sportclub-met-zn-beste-tijd-achter-zich)
om AJAX te willen toepassen zul je het meeste werk moeten doen in Javascript (vooral in de toepassing van DOM, het doorlopen van nodes als je ook XML toepast ... óf als je kiest voor de gerealteerde techniek JASON het versturen en uitvoeren van complete javascript-objecten).. PHP-kennis (of wat voor serverside gebaseerde data-generartietaal is dan meestal niet zo belangrijk)

[Verwijderd]

Oké, duidelijke omschrijving van RM-rf. Het klopt dat het mij nog niet geheel helder is. Ik zal onderzoeken of het in mijn situatie voldoende voordeel oplevert AJAX toe te passen.

[killercow]

Wat de normale gang van zaken is:

[html]                  structuur, google op semantiek
 + [images]          content
 + [css]               opmaak
       + [images]    grafische opmaak dmv images

Wat de gang van zaken is met een dynamische site:

[php]                   je programma
 + [mysql]           database backend
  \/                      php maakt html
[html]                  structuur, google op semantiek
 + [images]          content
 + [css]               opmaak
       + [images]    grafische opmaak dmv images

De browser ontvangt dus altijd html.

Wat de gang van zaken is met een dynamische site versneld met ajax:

[php]                   je programma
 + [mysql]           database backend
  \/                      php maakt html en xml
[html]                  structuur, google op semantiek
 + [images]          content
 + [css]               opmaak
       + [images]    grafische opmaak dmv images
 + [javascript]       interactie binnen de pagina
      + [ajax]         "ajax" leest de door php gegenereerde xml
          + [dom]     "ajax" schiet nieuwe html het document in dmv dom functies.

Je gebruikt ajax dus om binnen een pagina nieuwe stukken html toe te voegen.
Door de initiele html netjes clean te houden, en de style en layout allemaal in css te doen heb je bij de laatste stap veel minder werk, je hoeft immers alleen tags toe te voegen via de Dom, niet ook nog eens de layout. En aangezien je XML ook alleen data bevat (en dus geen opmaak) kun je dit vrij simpel houden.

[Bozozo]

Even een algemene javascript tip: als je je HTML aanpast met javascript, doe dat dan 'buiten beeld'. Wat je vaak ziet is zoiets:

JavaScript:

var oldDiv = document.getElementById('contentdiv');
oldDiv.innerHTML = myAJAXResponsestuff;

Maar sneller is:

JavaScript:

var oldDiv = document.getElementById('contentdiv');
var newDiv = document.createElement('div');
newDiv.innerHTML = myAJAXResponsestuff;
oldDiv.parentNode.replaceChild(newDiv,oldDiv);

De innerHTML wordt dus gevoerd aan een div die nog niet aan de pagina is toegevoegd. Dit geeft een merkbare snelheidswinst bij grote lappen HTML (vooral als daar weer nodes inzitten zoals <b> tags), en dan vooral bij wat oudere browsers.

En, voor de volledigheid, een ander voordeel is dat je de oude content nu nog hebt (de return waarde van replaceChild is namelijk oldDiv).

[ Voor 16% gewijzigd door Bozozo op 02-07-2008 10:09 ]

[Peedy]

Hoezo is dat dan sneller? Ik geloof wel dat het zo is, maar het voelt intuitief niet zo aan (nieuw element aanmaken en dan replacen t.o.v. innerHTML overschrijven)...

Edit; ah..leg je het net uit

[ Voor 9% gewijzigd door Peedy op 02-07-2008 10:10 ]

[Mei]

Met alle respect, maar volgens mij weet de TS niet precies wat-ie nou wil. Het klinkt een beetje alsof je dit zegt: "Ik wil een 30 liter V23 TDI met flux capacitor in m'n Kever stoppen!".

AJAX (En AHAH for that matter) is niets meer dan een techniek om na de page load eventuele nabewerkingen aan de pagina (zoals een refresh van informatie) gemakkelijk te laten gebeuren. Sowieso moet je site nooit voor ook maar 1% op Javascript vertrouwen, aangezien JS niet altijd beschikbaar is. Verder is het stom om elke pagina te laten opbouwen door JS, want dat is extra langzaam. Het kost je meerdere requests (elk CMS heeft een bootstrapmodus die bij elke request doorlopen moet worden) en Javascript is sowieso langzamer dan PHP.

Mijn advies: Maak je site gewoon in PHP, eventueel met wat voorbereidingen om later gemakkelijk AJAX/AHAH toe te kunnen voegen. Gebruik die eventuele Javascript dan alleen als toevoeging, maar niet als essentiëel onderdeel van je website.

[Cousin Boneless]

Beetje off-topic misschien, maar als je site traag is doordat er veel html/tekst data (zeg > 100KB) moet worden verzonden, kun je veel winst behalen (tot zo'n factor 10) door je data te comprimeren:

PHP:

$canzip = preg_match('/(^|, *)gzip($| *,)/i', $_SERVER['HTTP_ACCEPT_ENCODING']);

function writeSiteHeader() 
{
    global $canzip;

    if ($canzip)
    {
        header('Content-Encoding: gzip');
        ob_start();
    }

    ...
}

function writeSiteFooter()
{
    global $canzip;

    ...

    if ($canzip)
        echo gzencode(ob_get_clean());
}

Bijkomend voordeel is dat je niet zo rap door je data limiet gaat. Uiteraard levert dit geen winst op bij content die al gecomprimeerd is (plaatjes, filmpjes etc). Keerzijde is dat de client iets meer belast wordt (met unzippen) en de pagina pas wordt opgebouwd als de laatste byte gelezen is.

[ Voor 1% gewijzigd door Cousin Boneless op 02-07-2008 23:17 . Reden: minder knullige regexp ]

[Noork]

Ik begrijp dus dat je tabellen met overzichten wilt voorzien van verse data? Kun je dan niet b.v. een grid gebruiken zoals Rico Livegrid (gebaseerd op Prototype) of jqGrid (gebaseerd op Jquery). Vooral die eerste is erg makkelijk in gebruik. Kwestie van een example pakken en de SQL query aanpassen. jqGrid kun je makkelijk vullen met o.a. json of xml data. De grids zijn verder prima te skinnen met CSS. Lijkt me handiger dan zelf het wiel weer opnieuw gaan uitvinden.

[ Voor 5% gewijzigd door Noork op 02-07-2008 22:37 ]

[Gomez12]

Mei schreef op woensdag 02 juli 2008 @ 10:21:
Sowieso moet je site nooit voor ook maar 1% op Javascript vertrouwen, aangezien JS niet altijd beschikbaar is.

Disagree, ik ken genoeg situaties waarin er gewoon als functionele eis lag dat er JS moest zijn ( intranetten / web-applicaties etc ).
JS kan voor mooie effecten zorgen en zolang jij altijd maar weer een non-JS fallback moet bouwen krijg je hogere kosten.
Als je al css-trucjes etc gebruikt kan je imho er ook wel redelijk vanuit gaan dat iemand JS heeft ( mits je een duidelijke doelgroep hebt ) een screenreader kent geen JS, maar kan afaik ook niet overweg met css-sprites.

Verder is het stom om elke pagina te laten opbouwen door JS, want dat is extra langzaam. Het kost je meerdere requests (elk CMS heeft een bootstrapmodus die bij elke request doorlopen moet worden) en Javascript is sowieso langzamer dan PHP.

Kan langzamer zijn, kan sneller zijn. Hangt er net vanaf hoeveel je wilt veranderen. Ben nu bezig met een web-app die 100% steunt op zoeken en dan items tonen met subitems in een popupmenu.
Zou ik de popup-divs allemaal bij de pageload versturen dan heb ik een risico dat er eventjes 50.000 items over het lijntje moeten en per search opdracht zou dit verschillen, nu met ajax-calls die alleen de aangeklikte popups aanmaakt stuur ik alleen een JSON-bestandje over de lijn heen dat aangemaakt wordt adhv het search-item. JS zet het JSON-bestandje om naar een popup inclusief markup etc.
Nu zit ik wel op extra requests, maar de paginagrootte is met een factor 5000 omlaag gegaan. De php-caching kan veel effectiever te werk gaan ( ik genereer nu meerdere kleine bestandjes die allemaal los te cachen zijn ipv 1 groot bestand wat bijna niet meer te cachen valt doordat het elke zoekopdracht wijzigt.

Het kan dus verschillen ( moet wel opmerken dat de 1e page-load inclusief de hoofditems wel volledig in php gegenereerd wordt, in 1e instantie ging dit ook via AJAX, maar die extra page-request was gewoon iets te duidelijk zichtbaar, nu dus alleen AJAX-calls voor de zoekopdrachten en het tonen van de resultaten )

Mijn advies: Maak je site gewoon in PHP, eventueel met wat voorbereidingen om later gemakkelijk AJAX/AHAH toe te kunnen voegen. Gebruik die eventuele Javascript dan alleen als toevoeging, maar niet als essentiëel onderdeel van je website.

Completely agree. Dit is in 90% van de gevallen een goed uitgangspunt. Zowieso ook al is je JS 100% noodzakelijk deze imho toch pas als laatste toevoegen, ik heb er een hekel aan om bij een probleem en de html en de php en de ajax-calls en de JS-scripts allemaal tegelijk te moeten debuggen. Gewoon eerst zorgen dat je php/html goed werkt, zodat als je iets met JS doet je 100% zeker weet dat als het niet werkt het in je JS zit...

[Mei]

Gomez12 schreef op woensdag 02 juli 2008 @ 22:51:
[...]

Disagree, ik ken genoeg situaties waarin er gewoon als functionele eis lag dat er JS moest zijn ( intranetten / web-applicaties etc ).
JS kan voor mooie effecten zorgen en zolang jij altijd maar weer een non-JS fallback moet bouwen krijg je hogere kosten.
Als je al css-trucjes etc gebruikt kan je imho er ook wel redelijk vanuit gaan dat iemand JS heeft ( mits je een duidelijke doelgroep hebt ) een screenreader kent geen JS, maar kan afaik ook niet overweg met css-sprites.

Veel webapps (zie spul van Google) zijn gewoon zonder JS te maken. Als het echt niet anders kan OK, maar dan is het ook echt een webapp en niet zozeer een website. Trouwens, CSS heeft bar weinig te maken met je content, Javascript veel meer, zeker met AJAX/AHAH.

[...]

Kan langzamer zijn, kan sneller zijn. Hangt er net vanaf hoeveel je wilt veranderen. Ben nu bezig met een web-app die 100% steunt op zoeken en dan items tonen met subitems in een popupmenu.
Zou ik de popup-divs allemaal bij de pageload versturen dan heb ik een risico dat er eventjes 50.000 items over het lijntje moeten en per search opdracht zou dit verschillen, nu met ajax-calls die alleen de aangeklikte popups aanmaakt stuur ik alleen een JSON-bestandje over de lijn heen dat aangemaakt wordt adhv het search-item. JS zet het JSON-bestandje om naar een popup inclusief markup etc.
Nu zit ik wel op extra requests, maar de paginagrootte is met een factor 5000 omlaag gegaan. De php-caching kan veel effectiever te werk gaan ( ik genereer nu meerdere kleine bestandjes die allemaal los te cachen zijn ipv 1 groot bestand wat bijna niet meer te cachen valt doordat het elke zoekopdracht wijzigt.

Of je nou Javascript of PHP gebruikt, een pagina met 50k items erop wil je sowieso niet hebben, want dan wordt je browser traag. Waar ik op doel is dat je niet zegmaar je basic pagina laadt (slechts enkele containers) en daarna met JS alles invult. Dat idee kreeg ik naar aanleiding van iets was de TS zei. Deze benadering is gewoon bullshit. Javascript gebruik je alleen als het daadwerkelijk iets toevoegt, niet als nutteloze blingfactor.

[...]

Completely agree. Dit is in 90% van de gevallen een goed uitgangspunt. Zowieso ook al is je JS 100% noodzakelijk deze imho toch pas als laatste toevoegen, ik heb er een hekel aan om bij een probleem en de html en de php en de ajax-calls en de JS-scripts allemaal tegelijk te moeten debuggen. Gewoon eerst zorgen dat je php/html goed werkt, zodat als je iets met JS doet je 100% zeker weet dat als het niet werkt het in je JS zit...

Mooie uitleg over het stapsgewijs werken. Zo simpel, maar vaak vergeten mensen het (mezelf incluis)