Kein Zugriff auf Objekt

[unknown]

Wie komm ich sonst daran?

Im einfachsten (und ich würde behaupten, das ist der Normalfall) so

obj = {  
  loadData: function() {  
    $.ajax({  
      url: "meine_url",  
      error: this.errHandler.bind(this)  
    });  
  },  
  errHandler: function() {  
    this.mfkt();  
  }  
};

Klar, ich kann Funktionen so verschachteln, dass ich die Settings, die ich an $.ajax() übergebe, im Success- und Error-Handler zur Verfügung habe. Aber:

• Funktionen zu verschachteln erzeugt schwer lesbaren Code

Aber selbst wenn man die Settings erst generisch zusammenbasteln muss, sehe ich da kein Problem

obj = {  
  mfkt: function() {  
    var ajaxoptions;  
  
    ajaxoptions = {  
      url: url("data/errorWithText.php"),  
      error: this.errHandler().bind(this, ajaxoptions);  
    };  
    loadData(ajaxoptions);  
  },  
  loadData: function(ajaxoptions) {  
    $.ajax(ajaxoptions);  
  },  
  err: function(ajaxoptions) {  
    this.loadData(ajaxoptions);  
  }  
};

Im Fall von https://github.com/jquery/jquery/blob/2.1.0/test/unit/ajax.js#L151-L183 gibt es außer »this« keine Möglichkeit, auf das letztlich verwendete Settings-Objekt zuzugreifen. Das Settings-Objekt ist in keiner Variable in einem der äußeren Scopes gespeichert.

Die Settings sind in der temporären Variablen {url:..., error:...} im Scope der anonymen Funktion, welche an asyncTest übergeben wird, gespeichert.
Eine Referenz auf dieses temporary wird der ajax-Funktion übergeben, welche es dann als Context des Errorhandlers bindet.
Dieser temporären Variablen noch ein deklaratives var zu verpassen macht es jetzt nicht komplexer.

Wenn ich $.get(), $.getJSON(), $.post() usw. anstatt der Low-Level-Funktion $.ajax() verwende, dann lässt kann ich das erzeugte Settings-Objekt auch nicht per Closure den Handlern zugänglich machen, denn es wird intern erzeugt.

Aber dann habe ich die Parameter die ich an diese Funktionen übergebe und lasse es mir ein weiteres mal intern erzeugen.

Bei der Objektorientierten Programmierung will man meist selbst this verwenden, um das aktuelle Objekt zu referenzieren.
Aber abraten, wenn der Defaultcontext definiert ist? Warum?

Sagte ich ja: Weil man den Kontext selbst kontrollieren will. Stichwort Function Binding.

Das "Aber abraten, wenn der Defaultcontext definiert ist? Warum?" war hier nicht auf

Bei der Objektorientierten Programmierung will man meist selbst this verwenden, um das aktuelle Objekt zu referenzieren.

bezogen, dann ist es ja klar, dass man es nicht nutzen kann. War schlecht ersichtlich, gebe ich zu.

Der Kontext von Event-Handlern ist seit langem so in »DOM 0« (sprich seit Netscape 2.0) definiert.

Bei DOM 0 Event-Handlern ist der Context klar ersichtlich, ich selbst speichere ja den Eventhandler am element
element.onevent = function() { alert(this) }
Es wird also mit element.onevent() gerufen.
Bei addEventListener ist es definiert https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.addEventListener#The_value_of_this_within_the_handler.
(Wobei ich die Beschreibung dort schon grenzwertig finde.)
Sinnvoller Weise kompatibel und jedes Framework muss es wiederum definieren.
Aber das Beispiel zeigt es doch ganz gut. jQuery hat sich hier auch für Kompatibilität entschieden. Das ist doch erst mal gut.

Ja, aber warum überhaupt? ... Man sollte es den Entwicklern überlassen, die auf Basis von jQuery High-Level-Anwendungen entwickeln.

Den Context bestimmt immer derjenige, welcher den Handler übergibt.
Nur wenn ihm dieser egal ist, bestimmt es das Framework, dann kann man diesen aber auch ignorieren.
Es sei denn, dieser, durch das Framework bestimmte Context, ist ein wichtiger Bestandteil, an den man anders nicht (vernünftig) herankommt. Wie in deinem letzten Beispiel.
Also dort fehlt das Element als Parameter, nicht der Defaultcontext als Element ist das Problem.
Diesen kann nutzen wer will, man sollte ihn aber nicht nutzen MÜSSEN.
Klar, wenn man von vornherein darauf verzichtet hätte hier einen Context sinnvoll zu setzen, wäre das aufgefallen.