[PHP] While loop met AJAX

  • Hallo,


    ik loop momenteel vast op een klein probleem waardoor ik niet echt meer helder kan kijken naar de code.
    Voor een klant van mij heb ik een zoekfunctie gemaakt, waarbij er gezocht moet worden in de DB bij bepaalde criteria. Dit lukt allemaal, echter komt er telkens maar een zoekresultaat uit...


    Nu is de oplossing dus een while loop, echter gebruik ik ook nog AJAX om alles dynamisch te laten verlopen, waardoor het toch iets lastiger is.


    De code is nu wat rommelig, dit komt doordat ik nu alles aan het uit proberen. De query zal later ook herschreven worden naar een prepared statement dus veiligheid is geen probleem.

    Door middel van json_encode stuur ik alles terug naar een Javascript bestand, hier werd alles goed uitgelezen en weergeven, echter laat $html maar één resultaat zien terwijl de query er op dit moment twee ophaalt. Er zijn dus wel degelijk twee records.


    Zou iemand dus misschien weten waaraan het ligt? Wellicht is het iets simpel of klopt er iets niet aan de while loop.


    Bij voorbaat dank,
    Reza.

  • Bedankt beide voor jullie reacties.


    Ik had van $html als laatste een array gemaakt, daarvoor was het een lege string waar ik steeds tekst bij toevoegde.


    PHP
    $html = ""
    $html .= 'Nieuw'

    Dit had ik dus eerst, wat Luc ook bedoeld.


    Edit:
    Door nog een klein stuk aan te passen, werkt alles nu. Bedankt Luc en Stijnhau!

  • Uhm, waarom retourneer je HTML als JSON :/.


    Doe (bij voorkeur) een van de twee volgende dingen:
    - retourneer het gewoon als HTML; als je een AJAX-call doet via jQuery kun je een "hint" meegeven over het te verwachten reponstype (dataType, met als waarde json of html)


    of, wellicht beter,
    - retourneer alleen relevante data als JSON, en genereer de HTML in je callback-functie


    Voordeel van de laatste methode is dat er veel minder data over de lijn gaat.


    Ik zou je afraden om in MySQLi over te stappen naar prepared statements. Dit is namelijk nogal ... ruk. Daarnaast heeft het geen enkele toegevoegde waarde en wordt alles mogelijk trager.


    Prepared statements in MySQLi zijn namelijk "echte" native prepared statements in-the-MySQL-sense-of-the-word, oftewel, elke SELECT-query resulteert in het daadwerkelijk uitvoeren van TWEE queries (1x voor de prepare, 1x voor de execute). En dan is de syntax van prepared statements in MySQLi nogal omslachtig.


    Dan nog iets heel anders: in alle discussies over het escapen van DATA heb je altijd te maken met een CONTEXT (HTML, SQL, et cetera) maar wat nogal eens altijd wordt vergeten is dat al die escaping functionaliteit alleen goed werkt als je op de correcte manier omspringt met je character encoderingen.


    Heb je bijvoorbeeld al gedacht aan de character encoding (CE) van:
    - je code-bestanden zelf, met welke CE zijn je PHP/HTML/etc-bestanden opgeslagen (wellicht minder doorslaggevend qua security, maar daarom niet minder belangrijk)
    - het gegenereerde HTML-document middels meta tag of PHP-header()
    - de connectie met je database middels een set_charset() functie
    - de CE van je tabellen
    - de CE waarmee de data in deze tabellen (daadwerkelijk) is opgeslagen?


    Ook in de Content-Type header van je JSON-respons zie ik geen CE aanduiding...


    Kun je bijvoorbeeld het volgende stukje goed tonen/transporteren:

    ?

  • Bedankt FangorN, zeer geïnteresseerd door wat je van mij vraagt.
    Nu heb ik hetzelfde systeem op mijn eigen site, waar ik dezelfde methodes gebruik(hiermee bedoel ik een dezelfde programmering).


    http://prntscr.com/869d4j -> Je kan hier zien dat ik dat invoeg
    http://prntscr.com/869dus -> Hier kan je zien dat ik het wel degelijk opsla
    http://prntscr.com/869e3g -> Nu je de URL bezoekt, zie je dus het resultaat.


    Nu is dit mijn eigen website, een project waar ik een tijdje niets mee heb gedaan. Alles is zelf gemaakt, behalve de editor en notify stukje. Ik denk dus dat jij dit bedoelde, of zit ik verkeerd...

  • Simpelweg omdat iets juist wordt weergegeven wil niet zeggen dat iets juist is opgeslagen.


    MySQL is redelijk intelligent als het gaat om vertalingen tussen verschillende character encoderingen dus het kan zijn dat daarom alles op dit moment goed getoond wordt... totdat je je CE van je document / je database-connectie een keer instelt.


    Het afwezig zijn van een CE-aanduiding in je Content-Type header van je JSON-response was mijn voornaamste aanleiding om hierop te reageren, naast de wat rare opzet van deze JSON-response dus... Dit zou wat mij betreft gewoon text/html moeten zijn (met CE) omdat het HTML is, geen JSON.


    Ik zou zeggen, denk er nog eens over na en controleer via je browser developer tools eens wat je CE van je document / AJAX response is en controleer of je een _set_charset() functie aanroept bij het maken van je database-connectie...


    EDIT: en het is dus beter om overal expliciet een "charset" in te stellen in je header()s.

  • Wellicht ben ik het vergeten te melden, maar MySQL heeft hier niets mee te maken.
    De editor voert alles via JS/AJAX door naar een ander PHP script en deze past de file direct aan.


    Alles wordt dus ook via de URL goed doorgegeven ;)

  • Wijkt dit niet af van je oorspronkelijke vraagstelling, daar heb je het wel over een database?


    Ik begrijp het niet helemaal meer? Speelt het oorspronkelijke probleem nog of is er een ander probleem?


    Ik denk dat we hier met zijn allen proberen dit soort vraagstukken op te lossen, of andere en mogelijk betere werkwijzen aan te dragen, maar die moeten dan wel gebaseerd zijn op een kloppend verhaal, anders gaan we niet van eenzelfde uitgangspunt uit en sluiten de adviezen hier niet bij aan...


    Dus eh... Geef ff opnieuw een situatieschets en vertel daarbij wat het probleem precies is - als er uberhaupt nog een probleem speelt.

  • Ik weet niet of je hebt opgelet, maar jouw eerste reactie kwam nadat ik al had gezegd dat het was opgelost.


    Mijn probleem was, dat ik maar één resultaat kreeg i.p.v. meerdere. Dat was opgelost door paar kleine aanpassingen.


    Nu had jij in je eerste reactie twijfels over mijn manier van gebruik, waarop ik een test uitvoeren op mijn eigen site (dus niet die van mijn klant). Er is dus helemaal geen probleem, ik antwoordde echter alleen maar op jouw berichten...


    Op mijn huidige site maak ik bij mijn editor geen gebruik van een database, echter is de code etc. allemaal hetzelfde als die van mijn klant. Topic kan gesloten worden, het werd in eerste instantie alleen maar opengehouden voor extra commentaar ^^

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!