Funktionsname == Variablenname /Konflikt

[pl]

S. Thema. Ich hab da einen Editor (Demoversion) womit einem Eintrag (url) beliebige Attribute => Value Paare hinzugefügt werden können. Wenn jedoch das Attribut 'checkin' heißen soll, streikt die Anwendung weil es bereits eine Funktion mit demselben Namen gibt.

Hat jemand eine Idee zur Konflikt-Vermeidung? Die Namen der Attribute sollten frei vergeben werden können.

MfG

[Schlaukluge Regina]

Hi hotti

Hat jemand eine Idee zur Konflikt-Vermeidung?

willkommen in der Realität. EAV, Framework (fw), Config, Pattern, Template Engine (TE), whatever (WE), ... (tbc) sind keine Eier legende Wollmilch (ElWs) oder sowas

Das hängt von der Anwendung ab! Beachte das. Verwende eine Struktur, ein Pattern oder WE dann und nur dann wenn es sinnvoll ist und nehm es nur wenn es auch auf den Fall passt und oder dafür angepasst ist.

Zu der Frage; beachte den Kontextwechsel (kw)! Immer! Auch wenn es nicht wie kw aussieht...

Einsicht und Erfolg man dir wünsche.

Grüßle Schlaukluge

[1unitedpower]

Wenn jedoch das Attribut 'checkin' heißen soll, streikt die Anwendung weil es bereits eine Funktion mit demselben Namen gibt.

Nicht die Funktion checkin, sondern die Objekt-Eigenschaft param.checkin sorgt in deinem Fall für den Namenskonflikt.

var param = { checkin: [document.getElementById('_url').value] };
//            ^^^^^^^
for(var i = 0; i < SLICE.length; i++){
   var hunt = SLICE[i];
   param[hunt.att] = [hunt.val];
//       ^^^^^^^^ Konflikt falls hunt.att === 'checkin'
}

Hat jemand eine Idee zur Konflikt-Vermeidung? Die Namen der Attribute sollten frei vergeben werden können.

Du kannst die hart-kodierten Eigenschaften von den benutzerdefinierten Eigenschaften trennen, bspw. so:

var param = {
   custom: Object.create(null),
   checkin: [document.getElementById('_url').value]
};
for(var i = 0; i < SLICE.length; i++){
   var hunt = SLICE[i];
   param.custom[hunt.att] = [hunt.val];
}

Object.create(null) ist eine weitere Verbesserung, Axel erklärt wieso.

PS: Es wäre hilfreich, wenn du beim nächsten Mal direkt auf die fragliche Codestelle verweisen würdest.

[pl]

Wenn jedoch das Attribut 'checkin' heißen soll, streikt die Anwendung weil es bereits eine Funktion mit demselben Namen gibt.

Nicht die Funktion checkin, sondern die Objekt-Eigenschaft param.checkin sorgt in deinem Fall für den Namenskonflikt.

var param = { checkin: [document.getElementById('_url').value] };
//            ^^^^^^^
for(var i = 0; i < SLICE.length; i++){
   var hunt = SLICE[i];
   param[hunt.att] = [hunt.val];
//       ^^^^^^^^ Konflikt falls hunt.att === 'checkin'
}

Nein. Also daran liegt das Problem nicht.

PS: Es wäre hilfreich, wenn du beim nächsten Mal direkt auf die fragliche Codestelle verweisen würdest.

Das Problem ist allgemeiner Natur.

MfG

[Raumfahrer]

Das Problem ist allgemeiner Natur.

ich werf mal völlig losgelöst das Stichwort Namensräume in den Raum

[1unitedpower]

Das Problem ist allgemeiner Natur.

Dann erzeuge doch mal einen isolierten Testfall, an dem sich das Problem nachvollziehen lässt.

[pl]

Das Problem ist allgemeiner Natur.

Dann erzeuge doch mal einen isolierten Testfall, an dem sich das Problem nachvollziehen lässt.

Das Problem tritt auf, wenn z.B. die id eines <input>-Elements genauso lautet wie der Name einer Funktion. In überschaubaren Anwendungen wird sich das sicher vermeiden lassen und was meine Anwendung betrifft, werde ich auch eine Lösung finden, davon bin ich überzeugt.

Die Stelle wo's kracht ist ein <label for="@att@"> bzw. das target <input id="@att@"> was einzig den Sinn hat, für das ensprechende Attribut (@att@ ist nur der Platzhalter) eine Löschmarkierung setzen zu können, damit es beim Speichern nicht übernommen wird. MfG

[JürgenB]

Hallo Rolf,

ich habe versucht, dein Problem nachzuvollziehen:

<form>
  <label for="XYZ">Eingabe</label>
  <input id="XYZ">
</form>

function XYZ(par) {
  console.log("XYZ aufgerufen",par)
}
document.querySelector("#XYZ").onchange = function() {
  console.log(this.value);
  XYZ(this.value);
}

Der Test hat aber wie erwartet funktioniert.

Gruß
Jürgen

[pl]

hallo und danke Dir,

ich habe versucht, dein Problem nachzuvollziehen:

Es ist systematischer Natur und die Lösung besteht darin zu verhindern, dass eine Benutzereingabe zur id gemacht wird. So und nur so geht das ;)

MfG

[pl]

hi nochmal;

ich habe versucht, dein Problem nachzuvollziehen:

Ich auch...

<input id="foo" onclick="foo()">

Ergibt: foo is not a function

Und genau das ist die Systematik im Falschmachen. Benenne die id anders, so lautet auch die Fehlermeldung anders: foo is not defined.

... aber die Lösung hab ich ja schon.

MfG

[JürgenB]

Hallo,

<input id="foo" onclick="foo()">

Ergibt: foo is not a function

das ist spannend, denn wenn man den Handler mit ele.onclick = foo oder per addEventListener notiert, geht es.

Gruß
Jürgen

[Mitleser]

<input id="foo" onclick="foo()">

Ergibt: foo is not a function

das ist spannend, denn wenn man den Handler mit ele.onclick = foo oder per addEventListener notiert, geht es.

Korrekt. Das liegt an der immer noch in vielen Clients vorhanden, aus Urzeiten überlieferten Unart, Elemente mit IDs in den globalen JS-Raum zu exportieren. Wenn man es aber direkt richtig macht "addEventListener", dann hat man das Problem nicht.

[pl]

<input id="foo" onclick="foo()">

Ergibt: foo is not a function

das ist spannend, denn wenn man den Handler mit ele.onclick = foo oder per addEventListener notiert, geht es.

Korrekt. Das liegt an der immer noch in vielen Clients vorhanden, aus Urzeiten überlieferten Unart, Elemente mit IDs in den globalen JS-Raum zu exportieren. Wenn man es aber direkt richtig macht "addEventListener", dann hat man das Problem nicht.

Das ist interessant. Wie kriege ich denn das Element

<input type="checkbox" id="foo" name="dmark">

aus dem globalen JS-Raum raus?

[Mitleser]

Das ist interessant. Wie kriege ich denn das Element <input type="checkbox" id="foo" name="dmark"> aus dem globalen JS-Raum raus?

Keine Ahnung, da lässt sich aber bestimmt was murksen. Ist nur überflüssig, wenn man es richtig macht: "addEventListener"

[pl]

Das ist interessant. Wie kriege ich denn das Element <input type="checkbox" id="foo" name="dmark"> aus dem globalen JS-Raum raus?

Keine Ahnung, da lässt sich aber bestimmt was murksen. Ist nur überflüssig, wenn man es richtig macht: "addEventListener"

Nochmal: Es gibt in der Anwendung weder ein onclick noch einen EventListener. Also hat auch der Konflikt nichts mit irgendwelchen Events zu tun.

MfG

[Mitleser]

Nochmal: Es gibt in der Anwendung weder ein onclick noch einen EventListener. Also hat auch der Konflikt nichts mit irgendwelchen Events zu tun.

Genau das war aber Dein Beispiel. Womöglich möchtest Du einfach nur aufhören, den globalen Namensraum mit Deinen JS-Funktionen belasten? Bring mal ein Beispiel, was Dein konkretes Problem konkret nachvollziehbar macht. Dein Beispiel scheint es ja nicht zu treffen.

[pl]

Nochmal: Es gibt in der Anwendung weder ein onclick noch einen EventListener. Also hat auch der Konflikt nichts mit irgendwelchen Events zu tun.

Genau das war aber Dein Beispiel. Womöglich möchtest Du einfach nur aufhören, den globalen Namensraum mit Deinen JS-Funktionen belasten?

Ich werd' mir mal angucken was man in Sachen Namespace noch so machen kann.

Im Übrigen hab ich die Lösung hier bereits gepostet und mittlerweile umgesetzt, die Anwendung ist produktiv und deswegen auch aus der Demo raus. mfg

[Mitleser]

Im Übrigen hab ich die Lösung hier bereits gepostet und mittlerweile umgesetzt

s/Lösung/Krücke/

[pl]

Im Übrigen hab ich die Lösung hier bereits gepostet und mittlerweile umgesetzt

s/Lösung/Krücke/

Bevor Du weitere Buzzworte hier verschleuderst, da ist noch ne offene Frage

[Mitleser]

Im Übrigen hab ich die Lösung hier bereits gepostet und mittlerweile umgesetzt

s/Lösung/Krücke/

Bevor Du weitere Buzzworte hier verschleuderst, da ist noch ne offene Frage

Da auch, ich bin zuerst dran.

[pl]

Nochmal: Es gibt in der Anwendung weder ein onclick noch einen EventListener. Also hat auch der Konflikt nichts mit irgendwelchen Events zu tun.

Genau das war aber Dein Beispiel. Womöglich möchtest Du einfach nur aufhören, den globalen Namensraum mit Deinen JS-Funktionen belasten? Bring mal ein Beispiel, was Dein konkretes Problem konkret nachvollziehbar macht. Dein Beispiel scheint es ja nicht zu treffen.

Es erzeugt jedoch dieselbe Fehlermeldung und trifft den Kern der Sache: Namen-Konflikt. Dass es nur ein Beispiel ist, war uns doch vorher schon klar oder?

[JürgenB]

Nochmal: Es gibt in der Anwendung weder ein onclick noch einen EventListener. Also hat auch der Konflikt nichts mit irgendwelchen Events zu tun.

dann liefere ein auf das wesentliche reduziertes Beispiel, das den Fehler zeigt. Mal schreibst du was von Funktionen, die wie die ID heißen, dann kommt ein Beispiel mit onlick. Ich habe keine Lust mehr auf weiteren Ratesport.

[Matthias Apsel]

Hallo JürgenB,

das ist spannend, denn wenn man den Handler mit ele.onclick = foo oder per addEventListener notiert, geht es.

Ersetze „den Handler mit ele.onclick = foo oder per addEventListener notiert“ durch „es richtig macht“.

Bis demnächst
Matthias