[Ajax/php] refresh na verwerking door ajax

[jbweb]

Ik heb net een redelijk simpel Login script gemaakt waarbij een gebruiker in kan loggen op een website.
Na de login kunnen er twee dingen gebeuren:
1- de gebruiker heeft één keuze mogelijkheid.
2- de gebruiker heeft meer keuze mogelijkheden.

Het gaat hier om een simpel lijstje, met bijvoorbeeld het aanpassen van profiel, opslaan van bookmarks, wijzigen avatar, enz.
Als er meer keuze mogelijkheden zijn is dit natuurlijk heel erg mooi, maar als er maar één keuze is, staat dit nogal kaal en/of raar.
Zou het niet geweldig zijn als je bij één keuze meteen doorgestuurd werd naar deze keuze!?

Daar ben ik nu dus mee bezig. Het login script gaat met een Ajax scriptje en een Stored Procedure kijken of men toegang heeft en zo ja, welke keuzes er zijn.

JavaScript:

function getCheckLoginData(Username,Password)
{
    xmlHttp = GetXmlHttpObject();
    if (xmlHttp == null) {
        alert ("Browser does not support HTTP Request");
        return;
    }
    var geturl = "get_login.php?user="+Username+"&pass="+Password+"&sid="+Math.random();
    xmlHttp.onreadystatechange = stateChangedCheckLogin;
    xmlHttp.open("GET",geturl,true);
    xmlHttp.send(null);
}

Dan wordt via het XML feedje een error terug gestuurd, of één of meer keuzes. Terug bij het onreadystatechange script wordt het lijstje opgebouwd en weergegeven met innerHTML.

PHP:

$xmlfile = xmlHeader();
$xmlfile .= "<response>\n";

$result = $mysqli->query("CALL sp_login('" . $_GET['user'] . "','" . $_GET['pass'] . "')");

while($rows = $result->fetch_assoc())
{
    if($rows['loginstatus'] == 0)
    {
        $xmlfile .= "\t<error>" . $rows['loginstatus_message'] . "</error>\n";
    } else {
        $xmlfile .= "\t<domain id=\"" . $rows['domain_id'] . "\">\n";
        $xmlfile .= "\t\t<customer>" . $rows['customer_name'] . "</customer>\n";
        $xmlfile .= "\t\t<domain_name db_name=\"" . $rows['domain_database'] . "\" db_user=\"" . $rows['domain_login'] . "\" db_pass=\"" . $rows['domain_password'] . "\">" . $rows['domain_name'] . "</domain_name>\n";
        $xmlfile .= "\t</domain>\n";
    }
}
$xmlfile .= "</response>\n";

print $xmlfile;

(ik weet dat al die mooie technieken misschien een beetje overkill zijn voor een simpel login script, maargoed, ik moet het ook op en of andere manier leren

De vraag nu is de volgende. Hoe kan ik zorgen dat er na het verwerken van m'n script een refresh plaatsvindt, maar dan enkel bij één keuze.

JavaScript:

function stateChangedCheckLogin() {
    if (xmlHttp.readyState == 4 || xmlHttp.readyState == "complete") {

        var xmlDoc = xmlHttp.responseXML;

        if (xmlDoc.getElementsByTagName("error")[0]) {
            document.getElementById('error').innerHTML = xmlDoc.getElementsByTagName("error")[0].childNodes[0].nodeValue;
        } else {
            var NewContent = "<fieldset><label><h1>Domeinen:</h1></label></fieldset>\n";
            NewContent = NewContent+"<ul id=\"domain_array\">";

            for( var i=0; i<xmlDoc.getElementsByTagName("domain").length; i++ ) {
                NewContent = NewContent+"<li><a href=\"home.php?domain="+xmlDoc.getElementsByTagName("domain")[i].getAttribute("id")+"\">"+xmlDoc.getElementsByTagName("domain_name")[i].childNodes[0].nodeValue+"</a></li>";
            }
            NewContent = NewContent+"</ul>";
            }

            document.getElementById('login').innerHTML = NewContent;
        }

    }
}

Wat ik al heb geprobeerd zijn een HTML meta refresh en JS document.location.reload().
Helaas werken ze beide niet omdat de HTML natuurlijk al geladen is voordat er met innerHTML wat wordt toegevoegd.
Ik loop nu even tegen een blinde muur aan, iemand een idee?

[SchizoDuckie]

Waarom doe je in *godesnaam* zo moeilijk met ajax.

Submit die form gewoon met een normale form submit (VIA POST!!!! Check nu je browser history eens... je username/passwords staan in je history ) en schotel de ingelogde gebruiker een nieuwe pagina voor?

Ik word een beetje moe van alle mensen die 'ajax' willen 'leren' op de verkeerde manier...
Verder, gebruik nou alsjeblieft een framework voor je ajax requests op een manier die al verzonnen is en ga niet wéér het wiel opnieuw lopen uitvinden als je toch überhaupt al niet veel JS kennis hebt...

[ Voor 37% gewijzigd door SchizoDuckie op 06-02-2008 15:56 ]

[Verwijderd]

Als die for-loop klaar is en daarna (na de for-loop dus) is i gelijk aan 1 dan heb je er dus maar 1 ontvangen en kun je gaan redirecten ipv verdergaan?

verder met ^^^

edit
je kan het tr voor de for-loop ook al weten, immers is xmlDoc.getElementsByTagName("domain").length dan 1 (lijkt me, afhankelijk van xml-opbouw)

[ Voor 36% gewijzigd door Verwijderd op 06-02-2008 15:57 ]

[jbweb]

Ik had natuurlijk al verteld dat dit een te simpele tool was voor zo'n ajax script. Vervelend dat je moe wordt van mensen zoals mij!
Alleen begrijp ik niet waarom dit de verkeerde manier is om het te leren? Om meteen een heftige applicatie te maken gaat te ver als beginner en dit is niet het eerste dingetje wat ik maak. Het is ook een beetje oefening baart kunst.
Zolang mijn script werkt (omslachtig of niet) kan het toch niet "fout" zijn?

Maargoed. Ik kan natuurlijk ook een heel erg grote applicatie schrijven en dan vervolgens nog steeds tegen dit zelfde probleem aanlopen.
Het gaat eigenlijk over het probleem en niet mijn beginners enthousiasme

[SchizoDuckie]

jbweb schreef op woensdag 06 februari 2008 @ 16:00:
Alleen begrijp ik niet waarom dit de verkeerde manier is om het te leren? Om meteen een heftige applicatie te maken gaat te ver als beginner en dit is niet het eerste dingetje wat ik maak. Het is ook een beetje oefening baart kunst.
Zolang mijn script werkt (omslachtig of niet) kan het toch niet "fout" zijn?

*WRONG* Zo te zien weet je nog niet goed het verschil tussen GET en POST, dát is een van de eerste dingen die je jezelf toch eerst even moet aanleren.

Verder: "zolang het werkt kan het niet fout zijn" zijn famous last words voor programmeurs. Vooral van programmeurs die een dag later hun sites gehacked krijgen.

Op het moment dat je tegen een probleem als dit aanloopt hoor je jezelf af te vragen of je niet op de verkeerde manier bezig bent. Zelfreflectie hoort je dan daarna te zeggen: Ja, dit kan veel simpeler. Daarna hoort je verstand het weer over te nemen en hoor je dit netjes om te coden naar iets wat zonder een xml tussenlaag werkt

Als je dan echt gewoon 'iets met ajax' wilt uittesten, maak dan een echte testcase aan, en probeer hiet niet gelijk op een van de meest kritische onderdelen van je site uit zou ik zeggen

[ Voor 26% gewijzigd door SchizoDuckie op 06-02-2008 16:07 ]

[Patriot]

Je zou een extra entry in die XML file kunnen doen natuurlijk, waarin je het aantal keuzes zet. Dan haal je net zoals je kijkt of er een error is die tag op, en kijk je wat de waarde is. Als die waarde 1 is dan doe je window.location = window.location;. De browser zal dan refreshen.

EDIT: @SchizoDuckie: Ik denk dat hij doelde op het feit dat AJAX hier niet echt voor nodig is, niet op het gebruik van een POST request in plaats van een GET request.

EDIT: @Onder mij: Eval is evil.

[ Voor 27% gewijzigd door Patriot op 06-02-2008 16:12 ]

[borft]

als ik jou was zou ik eens naar xajax kijken, dat vind ik persoonlijk een erg fijne ajax library.

verder zou ik niet je user/pass submitten met GET, aangezien die dan in de accesslog van je webserver komen, om maar niet te spreken over je browser cache, proxy cache, etc.

Als je javascript code in de html zet die je terug stuurt, wordt deze niet automatisch uitgevoerd.

Wat je kunt proberen is iets als het volgende:

1. plak je html code in je document
2. zoek in de nieuwe code naar script tags (document.getElementsByTagname("script"))
3. pak de innerHTMl daarvan
4. eval die innerhtml als js

Maar of je dat wilt is de vraag. Als ik jou was zou ik je login formulier gewoon posten

[ Voor 43% gewijzigd door borft op 06-02-2008 16:09 ]

[giMoz]

jbweb, wat ons schizofrene eendje denk ik probeert te zeggen is dat AJAX geen doel is maar een middel.
En een middel wat jij op dit moment verkeerd inzet om een inlogprocedure te bouwen.
Daar is AJAX simpelweg niet voor bedoelt.

Mocht je het al zonder page refresh willen proberen zou je de username & password mee moeten geven in de post (de "xmlHttp.send(null); " regel) zodat ze niet in de browser historie om iig nog een beetje beveiliging aan te brengen.

[giMoz]

borft schreef op woensdag 06 februari 2008 @ 16:07:
4. eval die innerhtml als js

over een security leak gesproken.....

[SchizoDuckie]

giMoz schreef op woensdag 06 februari 2008 @ 16:11:
[...]


over een security leak gesproken.....

Het gemiddelde javascript framework zal niet veel anders doen om de scripts die via ajax terugkomen te executen in de page scope

[Verwijderd]

En als je dan toch op de nette tour bent, flikker dan heel snel je innerHTMl er uit en bouw netjes dom-elements.

En als je minder moeilijk wielen uit wil vinden kan je ook eens naar http://mootools.net kijken.

[jbweb]

Phewww... da's flink commentaar! Bijna genoeg om een anthousiast ajax beginner van zijn zelfgebouwde voetstuk te halen

Maargoed, het levert dan ook een boel op. Het probleem is inmiddels opgelost met de input van Herelam, ondanks de flink kritische noot van SchizoDuckie en giMoz heb ik weer wat geleerd over GET en POST in JS. Ik gebruik het al jaren keurig in html, maar wist inderdaad niet zo goed hoe het in JS toe te passen.
En ik ga zeker eens aan de slag met de mootools. Niet geheel onverdienstelijk dus! Waarvoor dank

Toch nog even een kleine reactie.
Gelukkig gaat het over een testcase voor mijzelf, het is geen live site of andere te hacken handel. In dit geval gaat het dus niet over kritieke onderdelen en recurity leaks, maar echt over een leer-curve.
Voor een live site zal ik zeker zoveel mogelijk uit mijn bestaande kennis putten en mijn inlog nooit aan de ajax hangen

Dus rest mij enkel nog de nette DOM elementen van elguapo i.p.v. mijn innerHTML.
Alleen is die me nog niet duidelijk genoeg. (idd JS newbie)

[Patriot]

Hij bedoeld geloof ik zoiets:

JavaScript:

// Element waar uiteindelijk alles in terecht komt
var parent = document.getElementById('parent');

// Nieuw div-element en textnode maken
var newDiv = document.createElement('div');
var newText = document.createTextNode('De inhoud van het divje');

// In elkaar gooien
newDiv.appendChild(newText); // Text in de div
parent.appendChild(newDiv); // Div in de parent

EDIT: @onder: Ik denk niet dat hij nu pas heeft besloten dat het een test betreft, ik ga er van uit dat hij gewoon al die tijd wat aan het ontdekken was wat er met AJAX kan.

[ Voor 17% gewijzigd door Patriot op 06-02-2008 16:58 . Reden: typo in de code, reactie op SchizoDuckie ]

[SchizoDuckie]

Maak je niet zo druk over het opbouwen van een complete DOM vs innerHTML. Ik gebruik zelf ook voornamelijk innerHTML voor het vervangen van complete bakken met HTML en alleen de fetisjisten vermaken zichzelf met het omzetten van xml naar html dom elements De rest van ons krijgt gewoon per uur betaald en heeft geen zin om 2x hetzelfde te doen. Je bent gewoon veel flexibeler met innerHTML (kijk even naar de update:divname parameter van je mootools Ajax request)

Goed dat je besloten hebt dat dit echt alleen een test is en dat je wat geleerd hebt, keep up the good work

[ Voor 21% gewijzigd door SchizoDuckie op 06-02-2008 16:58 ]

[FragFrog]

SchizoDuckie schreef op woensdag 06 februari 2008 @ 16:56:
Je bent gewoon veel flexibeler met innerHTML (kijk even naar de update:divname parameter van je mootools Ajax request)

Zo dacht ik er ook over tot ik wat ingewikkeldere dingen ging doen met Ajax. Werkte allemaal prima. In IE.

Om de een of andere reden lijkt FireFox een verwend nest te zijn als het aankomt op elementen weer verwijderen. Ben er nooit helemaal achter gekomen waarom, maar JS die geen errors opleverde in zowel IE als FF kreeg het toch soms niet voor elkaar een element dat geinjecteerd is met innerHTML weer te verwijderen in FF - ik heb een vaag vermoeden dat getElementById elementen die na renderen toegevoegd worden niet altijd kan vinden, maar zoals gezegd, nooit helemaal uitgeplozen.

Long story short, gooi je die hele handel in een domtree kun je wel netjes de node eruit halen die je wilt en werkt het wel altijd perfect. Iets meer werk maar uiteindelijk ook veel beter onderhoudbare code

[borft]

Mee eens, netjes alles volgens DOM doen geeft wel mooie code, alleen soms moet iets even snel gebeuren. Nadeel is dan wel dat je van de goedheid van de browser afhankelijk bent, of je elementen die je erin gepleurd hebt nog in de DOM kunt terugvinden.

JS evaluaten is idd een securiy risico, maar dat is natuurlijk altijd zo als je dynamische js code clientside wilt runnen.

[SchizoDuckie]

FragFrog schreef op woensdag 06 februari 2008 @ 17:31:
[...]

Om de een of andere reden lijkt FireFox een verwend nest te zijn als het aankomt op elementen weer verwijderen. Ben er nooit helemaal achter gekomen waarom, maar JS die geen errors opleverde in zowel IE als FF kreeg het toch soms niet voor elkaar een element dat geinjecteerd is met innerHTML weer te verwijderen in FF

Daar gebruik je nou juist een framework voor voor dat soort vaagheden:

JavaScript: mootools.js

/*
    Property: empty
        Empties an element of all its children.

    Example:
        >$('myDiv').empty() // empties the Div and returns it

    Returns:
        The element.
    */

    empty: function(){
        Garbage.trash(this.getElementsByTagName('*'));
        return this.setHTML('');
    }

JavaScript: mootools.js

var Ajax = XHR.extend({

// { ... }

onComplete: function(){
        if (this.options.update) $(this.options.update).empty().setHTML(this.response.text); // <-----
        if (this.options.evalScripts || this.options.evalResponse) this.evalScripts();
        this.fireEvent('onComplete', [this.response.text, this.response.xml], 20);
    },

});

Zoals je ziet wordt er door het xmlhttpobject automagisch eerst netjes de div leeggepleurd, getrashed, etc, en daarna pas de innerhtml vervangen, zo heb je geen moeilijkheden cross browser