[jQuery] Variabele in .html() wordt niet juist getoond

[DeepFreeze.NL]

Ik wil met behulp van jQuery één functie maken waarmee ik verschillende dialogs kan openen. Aan de hand van het rel attribuut wordt toegewezen om welke dialog het gaat en welk html getoond moet worden. Met het tonen van het html kom ik in de problemen.

Als ik de code: .html(origineel_emailadres_wijzigen) gebruik dan wordt netjes de var origineel_emailadres_wijzigen met de daarbij horende html ingeladen.

Doe ik html('origineel_'+rel) dan komt er (Als ik op de knop link e-mailadres wijzigen druk) te staan: origineel_emailadres_wijzigen, maar wordt niet de html van de betreffende var ingeladen.

Hoe kan ik het voor elkaar krijgen dat de html wel ingeladen wordt?

JavaScript:

$(document).ready(function() {
    
    // Origineel van form opslaan.
    var origineel_emailadres_wijzigen = $('#emailadres_wijzigen').html();
    var origineel_wachtwoord_wijzigen = $('#wachtwoord_wijzigen').html();
    
    $('.wijzigen').click(function() {
        
        // Target form uit rel attribuut halen.
        rel = $(this).attr('rel');
        
        //alert(origineel_+rel);
        // Met schone form beginnen.
        $('#'+rel).html('origineel_'+rel);
        //$('#'+rel).replaceWith('origineel_'+rel);
        //$('#'+rel).html({ data: 'origineel_'+rel });
        
        $('#'+rel).dialog({
            resizable: false, modal: true, width: 600, position: ['',140],
            buttons: {
                "Venster sluiten": function() { $(this).dialog("close"); },
                "Verstuur": function() {
                    $('#form_'+rel).ajaxForm({ target: '#output_'+rel });
                }
            }
        });
    });

});

HTML:

<a href="#" class="wijzigen" rel="emailadres_wijzigen">E-mailadres wijzigen</a>
<a href="#" class="wijzigen" rel="wachtwoord_wijzigen">Wachtwoord wijzigen</a>

<div id="emailadres_wijzigen" title="E-mailadres wijzigen" class="dialog">
<form action="post.php" method="post">
<div id="output_emailadres_wijzigen" class="jqm-content"></div>
<p>Uw e-mailadres wijzigen</p>
</form>
</div>

<div id="wachtwoord_wijzigen" title="Wachtwoord wijzigen" class="dialog">
<form action="post.php" method="post">
<div id="output_wachtwoord_wijzigen" class="jqm-content"></div>
<p>Uw wachtwoord wijzigen</p>
</form>
</div>

[Zoefff]

Wat gebeurt er als je de variabele met de html logt (console.log) op het moment dat je het wilt schrijven? Probeer bij het assignen op regel 4 en 5 eens een clone op te slaan i.p.v. de 'normale' html. Volgens mij loop je hier tegen een referentieprobleem aan. That is, wat er in je variabelen origineel_emailadres_wijzigen wordt opgeslagen is geen kopie maar een referentie naar de html. Wanneer je die in het formulier aanpast naar het nieuwe form, wordt dit 'in' de variabele ook aangepast, waardoor je per saldo geen verschil meer ziet.

Misschien heb ik het bij het verkeerde eind omdat ik niet precies weet hoe de jquery html() functie werkt, maar ik denk dat je het in deze hoek moet zoeken

[gvdh]

Vergelijk

JavaScript:

var origineel_emailadres_wijzigen = $('#emailadres_wijzigen').html(); 
//...
html(origineel_emailadres_wijzigen)

met

JavaScript:

html('origineel_'+rel)

In het eerste geval plaats je de html erin die je voordien hebt opgehaald. In het tweede geval plaats je letterlijk de string 'origineel_emailadres_wijzigen'. Je moet hier dus ook eerst de inhoud gaan ophalen.

[Rekcor]

Zie reactie gvdh.

Dit werkt waarschijnlijk dan weer wel:

JavaScript:

var origineel = {};
var origineel['emailadres_wijzigen'] = $('#emailadres_wijzigen').html(); 

var rel = $(this).attr('rel'); 
$('#'+rel).html(origineel[rel]); 

Overigens zou ik niet $(...) gebruiken, maar jQuery(...). Iets met namespacing enzo .

[DeepFreeze.NL]

Rekcor schreef op dinsdag 22 juni 2010 @ 14:03:
Zie reactie gvdh.

Dit werkt waarschijnlijk dan weer wel:

JavaScript:

var origineel = {};
origineel['emailadres_wijzigen'] = $('#emailadres_wijzigen').html(); 

var rel = $(this).attr('rel'); 
$('#'+rel).html(origineel[rel]); 

Overigens zou ik niet $(...) gebruiken, maar jQuery(...). Iets met namespacing enzo .

Dat werkt inderdaad wel (thanks!). Al snap ik eerlijk gezegd nog steeds niet waarom dit wel werkt...

[Bosmonster]

Rekcor schreef op dinsdag 22 juni 2010 @ 14:03:

Overigens zou ik niet $(...) gebruiken, maar jQuery(...). Iets met namespacing enzo .

Leg uit.

Als je een plugin ontwikkelt die compatible moet zijn met de noConflict-modus, dan ja, dan behoor je jQuery te gebruiken ipv $ (of deze alleen in lokale namespace te gebruiken). Als je gewoon een script schrijft kun je natuurlijk gewoon $ gebruiken.

Namespaces hebben daar niks mee te maken, aangezien beide variabelen toch al gebruikt zijn.

De enige keer dat dit een probleem oplevert is als je andere, wel global namespace-vervuilende, libraries gebruikt zoals Mootools of Prototype. Maar daar heb je dus de noConflict-modus voor.

Wees wat dat betreft blij dat jQuery dat hanteert, want voor de andere libraries is een dergelijke oplossing niet mogelijk. jQuery mag wat dat betreft de rotzooi opruimen die andere libraries achterlaten.

[ Voor 65% gewijzigd door Bosmonster op 22-06-2010 14:33 ]

[Rekcor]

DeepFreeze.NL schreef op dinsdag 22 juni 2010 @ 14:22:
[...]

Dat werkt inderdaad wel (thanks!). Al snap ik eerlijk gezegd nog steeds niet waarom dit wel werkt...

Jij wilt de waarde van een variabele krijgen, waarbij de naam van die variabele ook variabel is.

JavaScript:

'origineel_'+rel

In Javascript zijn weliswaar alle globale variabelen een eigenschap van het window-object, maar het is netter om een object te maken, met als eigenschap je variabele. Je kunt namelijk naar een eigenschap van een object verwijzen met

JavaScript:

myObject[naam_van_variabele];

waarbij naam_van_variabele een vaste string kan zijn

JavaScript:

myObject['hoi'];

of een variabele

JavaScript:

var myVar = 'hoi';
myObject[myVar];

[Rekcor]

Bosmonster schreef op dinsdag 22 juni 2010 @ 14:28:
[...]


Leg uit.

Als je een plugin ontwikkelt die compatible moet zijn met de noConflict-modus, dan ja, dan behoor je jQuery te gebruiken ipv $ (of deze alleen in lokale namespace te gebruiken). Als je gewoon een script schrijft kun je natuurlijk gewoon $ gebruiken.

Namespaces hebben daar niks mee te maken, aangezien beide variabelen toch al gebruikt zijn.

De enige keer dat dit een probleem oplevert is als je andere, wel global namespace-vervuilende, libraries gebruikt zoals Mootools of Prototype. Maar daar heb je dus de noConflict-modus voor.

Wees wat dat betreft blij dat jQuery dat hanteert, want voor de andere libraries is een dergelijke oplossing niet mogelijk. jQuery mag wat dat betreft de rotzooi opruimen die andere libraries achterlaten.

Overigens heeft Mootools ook een vervanging van de $-functie: document.id.

Laat ik zeggen dat ik '$' een weinig zeggende naam vind. JQuery zegt ook niet veel, maar tenminste wel dat het een jQuery-functie is. Zeker in situaties waarbij je gedwongen wordt om met Moo en Jquery te werken, is het m.i. goed om 'jQuery' te gebruiken, zodat altijd duidelijk is wat je bedoelt.

Aangezien je niet van te voren weet of jouw code binnen een dergelijke context gebruikt gaat worden, is het m.i. goed om jezelf aan te wennen altijd 'jQuery' te gebruiken.

[Bosmonster]

Mocht je ooit verplicht zijn met ander libraries samen te werken, kun je alsnog noConflict hanteren en een anonieme functie voor de local namespace.

Om je op dit soort uitzonderingen op een dergelijke manier voor te bereiden lijkt mij wat overdreven. Zolang je zorgt dat plugins noConflict-compatible zijn is er niks aan de hand.

En ik heb de situatie nog niet meegemaakt dat ik niet van te voren weet in welke omgeving mijn code gebruikt gaat worden. Het is eerder andersom, dat je moet werken in reeds bestaande code en dan kun je er alsnog rekening mee houden (en zou ik alsnog kiezen om gewoon $ te gebruiken binnen een local namespace, scheelt gewoon een hoop typewerk en houdt de code overzichtelijker mijnsinziens)

[ Voor 37% gewijzigd door Bosmonster op 22-06-2010 16:18 ]

[pieturp]

@Rekcor
Eens met Bosmonster. Bij kleine(re) projecten gebruik ik een eigen $() functie die simpele selectors accepteert. Simpelweg omdat iedereen er vanuit gaat dat dat is wat die dollar-functie doet: DOM elementen teruggeven op z'n minst.

Als ik voor elke dom-query een complete library-naam én method-naam moet meegeven ben ik morgen nog niet uitgetypt!

/offtopic

[Bosmonster]

pieturp schreef op woensdag 23 juni 2010 @ 00:20:
@Rekcor
Eens met Bosmonster. Bij kleine(re) projecten gebruik ik een eigen $() functie die simpele selectors accepteert. Simpelweg omdat iedereen er vanuit gaat dat dat is wat die dollar-functie doet: DOM elementen teruggeven op z'n minst.

Als ik voor elke dom-query een complete library-naam én method-naam moet meegeven ben ik morgen nog niet uitgetypt!

/offtopic

Yikes. Dat vind ik dan wel weer verschrikkelijk. Zo heb ik me al eens suf gedebugged en kwam erachter dat iemand blijkbaar zo 'slim' was geweest zelf een $-functie aan te maken wat niet meer was dan een getElementByID-wrapper.

Pak dan Sizzle op zn minst ofzo, ipv een eigen zeer beperkte implementatie. Want compatible is het toch niet, dus is het zinloos daar speciaal die $ voor te willen gebruiken.

Nu maak je het jezelf alleen maar lastiger als dat kleine project ineens groter moet en je wel een library wil gebruiken. Kun je je oude code gaan herschrijven, of compatibility-modus gaan gebruiken, alleen maar door die stomme $-var.

[ Voor 11% gewijzigd door Bosmonster op 23-06-2010 07:49 ]

[pieturp]

Nee gewoon document.querySelectorAll(). Dus niet voor IE en inderdaad oppassen dat je project niet te groot wordt

Mij lijkt trouwens dat $('id') toch een belletje had moeten doen rinkelen. 't Is immers niet $('#id')

[Bosmonster]

pieturp schreef op woensdag 23 juni 2010 @ 11:41:
Nee gewoon document.querySelectorAll(). Dus niet voor IE en inderdaad oppassen dat je project niet te groot wordt

Mij lijkt trouwens dat $('id') toch een belletje had moeten doen rinkelen. 't Is immers niet $('#id')

Dat ligt eraan, andere libraries gebruiken die $ gewoon als shortcut voor getElementByID (in dit geval Mootools). Daarnaast is dat natuurlijk het punt niet.

Het is gewoon zinloos jezelf problemen op de hals te halen door libraries te gaan mimicken zonder dat je compatible bezig bent. Als je dan eens moet upgraden ben je de sjaak, en dat alleen maar doordat je perse een variabele-naam wilt gebruiken.

[ Voor 21% gewijzigd door Bosmonster op 23-06-2010 12:11 ]

[DeepFreeze.NL]

Bedankt voor je uitleg Rekcor!

[pieturp]

Bosmonster schreef op woensdag 23 juni 2010 @ 12:06:
[...]


Dat ligt eraan, andere libraries gebruiken die $ gewoon als shortcut voor getElementByID (in dit geval Mootools). Daarnaast is dat natuurlijk het punt niet.

Het is gewoon zinloos jezelf problemen op de hals te halen door libraries te gaan mimicken zonder dat je compatible bezig bent. Als je dan eens moet upgraden ben je de sjaak, en dat alleen maar doordat je perse een variabele-naam wilt gebruiken.

offtopic:
Volgens mij maak je 't mogelijk alleen anderen lastig. Als je geen library wilt gebruiken (omdat dat echt nog steeds vaak overkill is) vind ik een $ als functienaam prima geschikt voor een dom-querier. Dat doen die andere frameworks (libraries, zo je wilt) toch ook?! En die hebben toch ook die oh-ik-was-'t-net-ff-anders-gewend-quirks??