Eclipse Neon 1 – Standard-JSDT mit Schwächen – zusätzliche Plugins

Im September 1016 wurde die neue Eclipse-Version NEON I veröffentlicht. Ich hatte mir zuvor im Sommer bereits die R-Version angesehen. Während das PDT-Plugin für PHP unter NEON gut aussieht und seine Dienste auch für PHP 7 in gewohnter Weise leistet, kam bei einem Blick in die JSDT-Ecke eher ein wenig Enttäuschung auf.

Zwar gilt:
Der neue JS-(Esprima)-Interpreter kann sehr gut mit “ECMAScript 6”-Syntax [ES6]. Auch der Outline-Bereich funktioniert z.B. für die Anzeige definierter Objekt-Methoden/Funktionen, die über die neue ES6-Syntax mit “calss”-Statements angelegt werden, perfekt. Die gesamte Hierarchie von Objekt-Methoden/Funktionen und -Variablen wird dabei angezeigt. Gut gefallen haben mir auch der Debugger, der Support von “node.js” und auch ein paar andere neue Features (siehe etwa https://www.youtube.com/watch?v=UxGwu2adzIc). Generell ist es begrüßenswert, dass engagierte Leute versuchen, JSDT auf ein neues, zeitgemäßes Niveau zu hieven !

Aber: Wer hat schon alle seine JS-Codes auf die ES6-Syntax umgestellt? Zumal nicht alle von Kunden genutzten Browser-Versionen ES6 unterstützen.

Und dann kommt beim originalen unmodifizierten JSDT von NEON ein wenig Frust auf:

Hat man seine Objekt-Methoden über die klassische Syntax und Definitionen in der Prototype-Chain festgelegt, wird die nächste Hierarchieebene “Objekt” => Funktionen und Variablen” für ein Objekt im Outline-Fenster leider nicht mehr angezeigt. Der Outline-View für Objekte endet dann auf der Ebene der Objektnennung – nur der oberste Level wird angezeigt, also das Objekt selbst, nicht aber seine Variablen oder Methoden/Prototype-Funktionen. Ich habe das gerade nochmal für ein frisch heruntergeladenes NEON I überprüft.

Das Outline-Tool liefert für ES(≤5)-Code also leider nicht mehr die Funktionalität, die man von Mars 2 und Vorgängerversionen gewohnt war. Ich weiß nicht, ob sich die Eclipse-JSDT-Entwickler darüber im Klaren sind, dass das fast einem KO-Kriterium für die Benutzung entspricht? Eine voll funktionierende Outline-Umgebung mit mindestens zwei funktionierenden Hierarchie-Ebenen ist für ein schnelles organisiertes Arbeiten bei komplexen Codes ein Muss.

Ein Test-Beispiel

Folgender simpler Testcode zeigt das Problem auf:

var z = 7; 
var GOCR = new GOCC();  

var xas = function() {
  var beta = GOCR.beta(); 	
	
  var yas = function () {
	  var loc_num = GOCR.alpha(); 	
	  var zzz = function() {
		  var fff = 'fff'; 
	  }; 
  };  
}; 

class UUC {
	constructor (x) {
		this.x = x; 
	}
	ucc_alpha() {
		this.y = 'yyyy'; 	
	}
}

function GOCC() {
	this.ax_str = 'ufo'; 
	this.vv_ay  = new Array('Enlarge'); 
}

	GOCC.prototype.alpha = function() {
		this.a_num = 7;  
	};
	
	GOCC.prototype.beta = function() {
		this.b_num = 8; 
		return this.bnum; 
	};

 
Mit dem unmodifiziertem JSDT von NEON I führt dies zu folgender Darstellung im Outliner:

not_expanding_object_prototype_functions

Man erkennt, dass zwar verschachtelte Funktionsstatements über mehrere Hierarchieebenen hinweg korrekt aufgelöst werden. Auch die Methoden der “UUC”-Klasse werden noch dargestellt. Die Funktionen aber, die einem Funktionsobjekt über dessen Prototype zugeordnet wurden, werden jedoch im Gegensatz zum JSDT von Eclipse Mars nicht im Outline-View angezeigt.

Workaround mittels “Webclipse JSjet” und “Tern”

nDiejenigen, die nicht auf eine originäre Lösung im Rahmen der weiteren JSDT-Entwicklung warten wollen, können ggf. auf das Webclipse JSjet-Plugin zurückgreifen (Eclipse Repository: https://www.genuitec.com/updates/webclipse/ci/). JSjet greift intern auf Tern-Funktionalität zurück. Nach der Installation bietet der Outliner für Objekte bzw. Objekt-Konstruktor-Funktionen wenigstens zwei Ebenen an. Allerdings muss man sich dafür nach jedem Neustart von Eclipse mit etwas nerviger Werbung für Webclipse und die Fa. Genuitec auseinandersetzen – und mir persönlich sind die Lizenzbedingungen nicht vollständig klar. Ein Blick in diese Ecke lohnt sich aber durchaus.

Ich habe testweise auch die wichtigsten “tern”-Plugins aus dem aktuellen Repository “http://oss.opensagres.fr/tern.repository/1.2.0/” installiert. Insgesamt habe ich dadurch neben einer bzgl. Class und Prototype verbesserten Outline-Darstellung auch eine vernünftige Autocompletion-Unterstützung für jQuery erhalten. Dies ist umso wichtiger, als der Entwickler für das bisher bewährte JSDT-jQuery-Plugin nach eignen Ausführungen auf seiner Github-Seite Probleme mit Neon hat und um Unterstützung bittet.

In einer Testinstallation versammeln sich dann neben dem JSDT-Plugin u.a. folgende Plugins für die JS-Entwicklung:
tern_plugins

Mit dem Resultat kann man leben:
expanding_object_prototype_functions_with_tern
Ich verstehe nicht, dass das, was da geboten wird, nicht schon in den Standard übergegangen ist, da ja beim neuen JSDT-Team auch jemand von der Fa. Genuitec, die hinter Webclipse steckt, dabei zu sein scheint.

Fairerweise muss man sagen, dass die Auflösung über mehrere Ebenen hinweg unter dem Standard JSDT für verschachtelte Funktionen sogar besser funktioniert als mit JSjet und Tern. Leider aber nicht für Objekt-Konstruktoren und Prototype-Funktionen nach alter ECMA-Syntax.

Ich hoffe auf ein noch besseres JSDT in der Neon 2 Version.

Nachtrag 01.04.2017:

Meine Hoffnungen – und vielleicht die anderer Leser – wurden leider nicht erfüllt. Umso interessanter erschien es mir, mich ein wenig genauer mit JSjet auseinanderzusetzen. Leider gibt es auch da nicht nur Positives zu berichten. Mehr findet ihr dazu in folgenden Blogposts:

Webclipse JSjet, Eclipse Neon 2 and the Outline View – what I like and what not – part I
Webclipse JSjet, Eclipse Neon 2 and the Outline View – what I like and what not – part II

jQuery: Aufruf von Objekt-Methoden im Rahmen der Event-Behandlung und der .each()-Funktion für Selektionen

Will man Funktionalitäten, die man in Javascript/jQuery-Projekten erfolgreich entwickelt hat, wiederverwenden, muss man modular arbeiten und seine Funktionen in übergeordneten Einheiten kapseln. Wie einige meiner Leser wissen, versuche ich diese Anforderungen u.a. über die Etablierung abstrakter Control-Objects [CtrlOs] und definierte “Methoden” solcher Objekte umzusetzen.

Einerseits können Konstruktorfunktionen für abstrakte CtrlOs über ihren “prototype” zusammenhängende funktionale Verfahren im Sinne einer reinen Funktionalklasse bündeln.
Anderseits repräsentieren CtrlOs in meinen Web-Projekten bei Bedarf aber auch zusammenhängende Web-Bereiche sowie deren konkrete HTML-Objekte. Sie bündeln dann alle erforderlichen Methoden zum Umgang mit Ereignissen auf diesen Objekten. CtrlOs abstrahieren dabei soweit als möglich von der konkreten HTML-Ausprägung und führen zu einer allgemeineren Repräsentation bestimmter HTML-Schlüssel-Objekte im JS-Code – wenn nötig über die Definition weiterer geeigneter Unter-Objekte des CtrlOs. Wiederverwendbarkeit reduziert sich dann meist auf ein geeignetes Matching der IDs von Schlüsselelementen sowie ein Matching von Selektionskriterien für einen neuen Anwendungskontext (sprich für eine andere Webseite).

Beispiele:
Für die Steuerung einer Bildgalerie auf unterschiedlichen Webseiten ist z.B. lediglich der übergeordnete Container für die Bilder zu bestimmen und es sind geeignete Kriterien zur jQuery-Selektion der beinhalteten Bilder über Parameter zu definieren. Und schon können die meisten vordefinierten Methoden des CtrlOs wieder zum Einsatz kommen. Ein anderes Beispiel würde etwa die Kontrolle der Ajax-Interaktionen eines normierten Form-Elements mit einem PHP-Server zur Durchführung und Statusüberwachung eines Dateiuploads bieten. Auch hier lassen sich alle Funktionalitäten in Methoden eines relativ abstrakten und wiederverwendbaren CtrlOs bündeln.

Unter “Methoden” verstehe ich dabei allgemeine Funktionsobjekte, die als Elemente der fundamentalen “prototype”-Eigenschaft der Konstruktor-Funktionen für das CtrlO und ggf. der Konstruktorfunktionen für Sub-Objekte des CtrlO definiert werden. (In Javascript stellen Funktionen Objekte dar.)

Ziel ist es also, die gesamte Event-Behandlung und auch andere Aufgaben vollständig über “Methoden” eines für die jeweilige Aufgabe “fachlich” zuständigen CtrlOs und eventueller passend definierter Unterobjekte abzuwickeln. Das CtrlO entspricht somit einem (Singleton-) Container, der die Funktionalität zur Abwicklung aller auftretenden Ereignisse und Aufgaben in geordneter und wiederverwendbarer Weise kapselt. (Über den “prototype”-Mechanismus lässt sich dann natürlich auch eine “Vererbung” in komplexeren Projekten realisieren.)

Nun ist jQuery ursprünglich nicht auf eine solche Logik ausgerichtet; es sind daher ein paar Klimmzüge erforderlich, um HTML-Objekte einer Webseite mit Methoden abstrakter JS-Objekte zu koppeln. Vor allem der this-Operator und sein unter jQuery oftmals wechselnder Kontext führen dabei immer wieder zu Missverständnissen und Kapriolen.

So lenken jQuery’s Event-Behandlungs-Funktionen, die für jQuery-Objekte (Selektionen) ausgeführt werden, den this-Kontext in den aufgerufenen Callback-Funktionen auf das jeweilige HTML-Element um. Sind die Callbacks nun Methoden eines CtrlO-Objekts, so passt dies meist nicht zu der Erwartung, die den Entwickler beim Methoden-Design geleitet haben dürfte – nämlich, dass this in der Methode auf das CtrlO-Objekt selbst verweist.

Ich werfe daher zunächst einen Blick auf den $.proxy()-Mechanismus, der einem unter jQuery zumindest im Fall des Event-Handlings hilft, die erforderlichen Aufgaben an CtrlO-Methoden zu delegieren und den Kontext des this-Operators gezielt auf das CtrlO selbst zu setzen.

Danach wende ich mich einer Frage zu, mit der man es auch immer wieder zu tun bekommt:

Wenn man innerhalb einer CtrlO-Methode über eine Selektion von HTML-Objekten mittels der jQuery-Objekt-Funktion $(..).each( …) iteriert – wie delegiert man dann die anstehenden Aufgaben zur Behandlung der selektierten HTML-Objekte an eine (andere) geeignete “Methode” des abstrakten CtrlOs?
Und wie nutzt man dabei den this-Operator, so dass wir einerseits eine Referenz auf das CtrlO selbst und andererseits aber auch eine Referenz auf das aktuell zu behandelnde HTML-Objekt erhalten?

Wir werden sehen, dass sich der Aufruf der gewünschten CtrlO-Methode nicht ganz so bequem wie im Falle der Event-Behandlung über den $.proxy()-Mechanismus bewerkstelligen lässt; wir werden aber auch sehen, dass ein solcher Aufruf über einen kleinen Trick durchaus auf einfache Weise und ohne Informationsverlust möglich ist.

CtrlOs und Einsatz des $.proxy()-Verfahrens zur Delegation der Event-Behandlung an Objekt-Methoden bei gleichzeitiger Kontrolle des this-Operators

Das Abfangen von Events und die anschließende Delegation der funktionalen Bearbeitung an Methoden eines CtrlOs kann man relativ bequem über den $.proxy()-Mechanismus erledigen. Man registriert dazu im Rahmen der Definition der Event-Behandlung mittels geeigneter jQuery-Objekt-Funktionen (wie etwa “click()” ) die Funktion $.proxy() als primären Callback der Event-Behandlungs-Funktion – also z.B. click( $.proxy(), …). Der Funktion $.proxy() selbst wird dann einerseits eine Kontext-Referenz und eine Methode des CtrlO zur Event-Behandlung als Callback übergeben. Diese Verschachtelung von Callbacks hört sich kompliziert an – sie ist faktisch aber sehr bequem. Der Ansatz führt typischerweise zu Code-Abschnitten der unten angegebenen Art.

Voraussetzungen: GOC (“Global Object Controller”) definiert im Beispiel ein globales Objekt; um ein Zumüllen des globalen Kontextes zu vermeiden, werden die benötigten CtrlOs im GOC erzeugt. Wir nehmen für unser Beispiel vereinfachend an, dass die IDs benötigter HTML-Elemente über irgendwelche Parameter ermittelbar sind.


GOC = new Constr_GOC(); 

function Constr_GOC() {
    ....	
    this["CtrlO_Form"] = new Constr_CtrlO_Form( ...parameterS ...); 
    ....
    this["CtrlO_Form"].register_form_events(); 
    ...
}

//  Constructor of a CtrlO for a certain form-Tag  
// -----------------------------------------------
function Constr_CtrlO_Form(... parameters ...) {
    ....
    // gather or define concrete IDs of relevant HTML-objects 
    // by some appropriate evaluation methods
  
    this.id_form     = "#" + " ... (evaluation of parameters) ..."; 	
    this.id_rad_stat = "#" + ...; 	
    this.id_rad_heur = "#" + ...;
    this.id_but_chk  = "#" + ...;
    .....
    ....
}

// Proxy solution to register event handlers for HTML-elements   
// -----------------------------------------------------------
// The behaviour of the HTML-elements shall be controlled by CtrlO-methods 

Constr_CtrlO_Form.prototype.register_form_events = function() {
	
	console.log("From Form - registering event handlers for some key elements of the form");
		
	// Click on any of the radio buttons
	// ----------------------------------
       	$(this.id_rad_stat).click(
       	    jQuery.proxy(this, 'radio_click')
      	);
        $(this.id_rad_heur).click(
            jQuery.proxy(this, 'radio_click')
        );
        $(this.id_rad_both).click(
            jQuery.proxy(this, 'radio_click')
        );
			
	// Button_Click 
	// ----------------
	$(this.id_but_chk).click(
	    jQuery.proxy(this, 'click_event')
	); 
		
	// Submit Event 
	// ------------
	$(this.id_form).submit(
	    jQuery.proxy(this, 'submit_ajax_chkfiles')
	); 
			
};	

// 
Methods of the CtrlO 
// ------------------------------- 
Constr_CtrlO_Form.prototype.radio_click = function(e) {
    .....
    e.preventDefault(); 
    // get the JS-pointer to the HTML-Object for which the event e was triggered   	
    var pointerToHtmlObject = e.target;  	
    ....
    // var attribute = $(pointerToHtmlObject).attr(.....); 
    ....	
}
Constr_CtrlO_Form.prototype.click_event = function(e) {
    ....
}
Constr_CtrlO_Form.prototype.submit_ajax_chkfiles = function(e) {
    ...
}

 
Zuerst werden die IDs relevanter HTML-Schlüssel-Objekte anhand verfahrensspezifischer Kriterien identifiziert. Dann werden Event-Listener und -Handler für diese HTML-Objekte über geeignete jQuery-Funktionen registriert. Die Callbacks ‘radio_click’, ‘click_event’, ‘submit_ajax_chkfiles’ entsprechen im Beispiel Methoden, die über den prototype der Konstruktorfunktion für das instanziierte CtrlO bereitgestellt werden. Der this-Parameter, der an die $.proxy()-Funktion übergeben wurde, weist dabei auf das Objekt “CtrlO_Form” – dieses wiederum ist ein Element des GOC.

Der Aufruf von Callbacks als Event-Handler über jQuery-Objekt-Funktionen wie “.click()” führt dazu, dass der this-Operator innerhalb der im Eventfall ausgelösten Funktion auf das HTML-Objekt (!) verweist. Dies gilt auch, wenn der Callback eine Objektmethode sein sollte. jQuery setzt intern den Kontext für den this-Operator in expliziter Weise! Das führt regelmäßig zur Problemen, da ein Entwickler bei der Ausformulierung von Methoden als Teil des “prototype” eines Konstruktors in der Regel erwartet, dass this auf das (später) erzeugte Objekt zeigen wird.

Das Zwischenschalten der $.proxy()-Funktion sorgt im obigen Beispiel deshalb dafür, dass die jeweils genannte Methode zur Eventbehandlung aufgerufen wird und dass der this-Operator innerhalb der aufgerufenen Methode (wie erwartet) auf das CtrlO und nicht auf das HTML-Objekt zeigt, für das der Event ausgelöst wurde.

Wie aber erhält man nun in der CtrlO-Methode einen Zeiger auf das HTML-Object? Nun dies ist über das Event-Objekt von JS möglich, dass der Methode über den proxy()-Mechanismus automatisch übergeben wird:

Constr_CtrlO_Form.prototype.radio_click = function(e) {...}

e.target liefert dann den gewünschten Zeiger auf das HTML-Objekt. Dieser Zeiger lässt sich dann wiederum für jQuery-Selektionen und zugehörige Funktionen einsetzen.

Der $.proxy()-Mechanismus erlaubt so die vollständige Übergabe der Event-Behandlung an Methoden abstrakter Objekte. Das Verfahren lässt sich im Gegensatz zum Beispiel natürlich auch auf den Aufruf der Methoden anderer Objekte als des aktuell aktiven Objekts verallgemeinern.

jQuery’s .each()-Funktion und der this-Operator

Das obige Beispiel hat verdeutlicht, dass die Kontrolle über den this-Operator für die Delegation der Eventbehandlung an abstrakte Objekt-Methoden wichtig ist.

Nun delegiert auch die Funktion .each() eines jQuery-Objekts (sprich einer Selektion), die Durchführung von Aufgaben im Zusammenhang mit jedem der identifizierten HTML-Objekten an eine Funktion, die als Callback mit vordefinierten Parametern – nämlich (index, element) – festgelegt werden muss (s. https://api.jquery.com/each/). Wie lenkt man die Aufgabendurchführung aber statt dessen auf eine passende Methode eines CtrlOs um? Und wohin weist der this-Operator innerhalb der zu definierenden Callback-Funktion?

Betrachten wir zunächst, wie die .each()-Funktion im Zusammenhang mit Selektionen praktisch zum Einsatz kommt. Wir nehmen im nachfolgenden Beispiel an, dass bestimmte IMG-Tags einer Bilder-Galerie durch die CSS-Klasse “enlarge” gekennzeichnet sein sollen. Die Verwendung von .each() sieht dann im einfachsten Fall etwa so
aus:


// iterate over all (IMG-) tags with css class="enlarge"
// -----------------------------------------------------
$(".enlarge").each(
	function () {
		// Note: this in this function points to the HTML object, here an identified IMG tag 
		.....
		// Code to perform actions, e.g. on the HTML object
		// console.log("id des HTML-Elements : " + $(this).attr("id"); 
		..... 	
	}	
);

 
Wir führen eine Selektion durch und definieren innerhalb von each() eine Callback-Funktion, die dann bestimmte Dinge im Zusammenhang mit jedem der ermittelten HTML-Objekte des DOM-Baums der Webseite durchführt. Z.B. könnten wir dessen Attribute oder CSS-Eigenschaften verändern oder aber Event-Listener implementieren, etc..

Wichtig ist, sich zu vergegenwärtigen, dass der this-Operator innerhalb der Funktion “function() {…}”, die pro Element der Selektion ausgeführt werden soll, auf das aktuell betroffene HTML-Element verweist! Gemeint ist hier tatsächlich die JS-Referenz auf den DOM-Knoten – und kein JQuery-Objekt einer Selektion. Dieser Unterschied ist wichtig : Will man nämlich jQuery-Funktionen, die für Selektionen (also ein jQuery-Objekt) definiert sind, anwenden, so ist zuvor $(this) zu bilden !

“function() {…}” muss bestimmte formale Voraussetzungen bzgl. der Parameter erfüllen. Deshalb kann man “function() {…}” nicht so ohne weiteres durch Callback-Verweise auf beliebige Funktionsobjekte des JS-Codes ersetzen. Es ergibt sich daher die Frage:

Wie kann man über die innerhalb von each() definierten Callback-Funktion “function() {…}” Methoden eines CtrlOs aufrufen und die Referenz auf den DOM-Knoten dabei weiterverwenden?

Nehmen wir mal an, unser Code-Schnipsel von oben sei Teil einer Methode eines CtrlOs, welches wiederum als Element eines globalen Objects GOC definiert sei. Innerhalb des CtrlO-Konstruktors werde im Beispiel eine Initialisierungs-Methode “init_img_control()” aufgerufen; sie möge die Selektion von (IMG-) Tags anhand der CSS-Klase “enlarge” durchführen und pro (IMG-) Tag Aktionen zur späteren Bildkontrolle ausführen. Diese Aktionen seien in der Methode “set_img_nr()” des CtrlO definiert:


GOC = new Constr_GOC(); 

function Constr_GOC() {

    ....
    this.CtrlO_Manipulate_Pics = new this['Constr_CtrlO_Manipulate_Pics']( ...parameter, ...);
    ....
    ....
    // Konstruktor eines CtrlO - this refers to the GOC 
    // -----------------------
    this.Constr_CtrlO_Manipulate_Pics = function(.. parameter, ...) {
        ....
        var numOfImgs = 0; 
        ....
        // "this" refers here to the CtrlO which is created via the present constructor 		
        ...
        this.init_img_control();
        .... 
    };

    // CtrlO-Methode init_img_control()
    // -----------------------------------	
    this['Constr_CtrlO_Manipulate_Pics'].prototype.init_img_control = function() {
	
        // this refers to the CtrlO
        ....
        $(".enlarge").each(
            function () {
                // Note: this points here to an HTML object, 
                // an identified img tag with the CSS class "enlarge" 
                ....
                // Code to perform actions, e.g. on the HTML object

                // console.log("id des HTML-Elements : " + $(this).attr("id"); 

                // ... We WANT TO CALL set_img_nr() - BUT HOW TO DO IT PROPERLY ??? ....
                .....
            }	
        );
        .....
        .....
    };

    // CtrlO-Methode set_img_nr() - to be used for each IMG-tag
    // -----------------------------------------------------------	
    this['Constr_CtrlO_Manipulate_Pics'].prototype.set_img_nr = function(ref_to_img_tag) {
        ....
        var img_nr = 0; 
        // Count the number of identified IMG tags
        this.numOfImgs++; 
        img_nr = this.numOfImgs; 
        ... 
        $(ref_to_img_tag).attr("imgNum", img_nr.toString() );  
        ....
    };

}

 
Wir haben hier nebenbei für Interessierte noch eine weitere zusätzliche Kapselung im GOC vorgeführt:

Die Konstruktor-Funktion für das CtrlO kann selbst als Element des globalen GOC definiert werden. Das GOC-Objekt erzeugt dann das CtrlO als weiteres Unterobjekt durch expliziten Verweis auf das als Konstruktor zu verwendende Funktionsobjekt (this[“Name_des_Funktionsobjekts“]) nach dem new-Operator. Dass sowas tatsächlich geht, ist hier aber nur eine Randnotiz (siehe hierzu den Blog-Artikel Javascript: Einsatz des new-Operators mit Variablen und dynamischer Vorgabe der Konstruktorfunktion).

Im Beispiel wird per “$(..).each()”-Funktion über selektierten Objekte iteriert; wir möchten dabei z.B. gerne jedes der per $(“.enlarge”) ermittelten <IMG>-Tags um eine neues künstliches Attribut ergänzen; so könnten wir in diesem Attribut etwa eine Nummer hinterlegen, die wir später zur Identifikation des Bildes nutzen. Die Attribut-Ergänzung soll im Beispiel über die Methode “set_img_nr()” des CtrlOs GOC[“CtrlO_Manipulate_Pics”] geschehen.

Das Dumme ist nun, dass this innerhalb von “function() {…}” auf das aktuell identifizierte HTML-Element – also ein <IMG class=”enlarge” … >-Tag – verweist. Wir müssen das CtrlO daher anders referenzieren. Aus Gründen der besseren Wiederverwendbarkeit wollen wir zur Identifikation des CtrlOs aber keinen Bezug auf eine explizite Bezeichnung von Unterobjekten des GOC heranziehen; wir woll vielmehr auf ein geeignetes “this” zurückgreifen, das unmittelbar auf das CtrlO verweist. Andererseits soll aber die CtrlO-Methode “set_img_nr()” auch einen Verweis auf den aktuellen HTML-Knoten (also das IMG-Tag) als Parameter erhalten.

Ein wenig Nachdenken führt zu folgender Lösung für die Methode init_img_control() :


    this['Constr_CtrlO_Manipulate_Pics'].prototype.init_img_control = function() {
	
        // this still refers to the CtrlO
        ....
        ....
        // Use a helper variable to store the reference to the CtrlO

       var this_CtrlO = this;  // "this_CtrlO" points to the CtrlO (=GOC["CtrlO_Manipulate_Pics"])
                               // we could have called the helper variable also "that"
        ....
        $(".enlarge").each(
            function () {
                // Note: "this" now points to the HTML object, here an identified img tag 
                // Note: the variable "this_CtrlO" is found by implicit search in nested JS-functions 
                ....				
                .....
                // Code to perform actions, e.g. on the HTML object
                // console.log("id des HTML-Elements : " + $(this).attr("id");
                .....
                // we refer to the appropriate method of the CtrlO via the helper variable  
                // and provide the reference to the <IMG> tag (=this) as a parameter 

                this_CtrlO.set_img_nr(this); 
                ....
            }	
        );
        .....	
    };

 
Alles gut!
Der Profi erkennt sofort den klassischen Trick: Wir merken uns vor der Durchführung der jQuery-Selektion die Referenz auf das CtrlO in einer lokalen Hilfs-Variablen “this_CtrlO”. Da wir uns vor der Selektion ja noch im Kontext
einer gewöhnlichen Objekt-Methode befinden, verweist “this” dort ja noch auf das übergeordnete Objekt.

In der Callback-Funktion “function() {…}”, die innerhalb von .each() definiert wird, rufen wir dann die gewünschte Methode des CtrlO explizit unter Nutzung der Objekt-Referenz “this_CtrlO.Methodenname” auf. Die Variable wird im Lösungsansatz durch implizite Suche im Kontext der umgebenden, kapselnden Funktion init_img_control() gefunden.

Innerhalb der Callback-Funktion “function() {…}” verweist this nun jedoch auf das aktuell zu behandelnde HTML-Objekt der Selektion. Diese Referenz auf das HTML-Objekt können wir deshalb als Parameter (this) an die Objektmethode übergeben. Das zu bearbeitende HTML-Objekt kann danach auch in der CtrlO-Methode eindeutig identifiziert und bearbeitet werden.

Hinweis: Das zwischenzeitliche Speichern der this-Referenz in einer anderen Variablen entspricht in anderen Lehrbuchbeispielen oft dem Einsatz einer Hilfsvariablen “that”.

Unschöne impliziter Variablen-Suche

Wir haben uns mit dem obigen Lösungsansatz allerdings ein unschönes Thema für die Code-Pflege eingehandelt, das mit dem Hoisting von Variablen in Funktionen zu tun hat und in komplexeren Codes bei Unachtsamkeit zu Problemen führen kann: Die Variable “this_CtrlO” darf innerhalb von “function() {…}” an keiner Stelle über var-Statements redefiniert werden – auch nicht nach dem Statement “this_CtrlO.set_img_nr(this);”. Man erkennt leider nicht zwingend, dass es sich eigentlich um einen Parameter handelt, der nach unten durchgereicht wird. Das würde man gerne etwas expliziter sehen.

Man könnte diesem Thema einerseits dadurch ausweichen, dass man die Werte in Variablen speichert, die über das GOC explizit adressiert werden. Das würde unsere Kapselung aber auch wieder durchbrechen. Besser erscheint eine Übergabe der Referenz als Parameter in den each()-Bereich. Ein anderer Ansatz besteht deshalb in der expliziten Übergabe an eine sog. “immediate function” – das ist zwar auch nicht optimal, aber schon ein wenig besser. Man erkennt die Variable wenigstens als Parameter. Ganz nach unten durchreichen kann man die Referenz auf das CtrlO in diesem Falle halt leider nicht.


    this['Constr_CtrlO_Manipulate_Pics'].prototype.init_img_control = function() {

        // this still refers to the CtrlO
        ....
        ....
        // Use a helper variable to store the reference to the CtrlO

        var this_CtrlO = this;  // "this_CtrlO" points to the CtrlO (=GOC["CtrlO_Manipulate_Pics"])
                                // we could have called the helper variable also "that"
        ....
        ( function (pointer_CtrlO) {	
              $(".enlarge").each(
                  function () {
                      // Note: "this" now points to the HTML object, here an identified img tag 
	
                      // get external reference to the CtrlO
                      var CtrlO = pointer_CtrlO; // best at the top of the function code 
                      ....				
                      .....
                      CtrlO.set_img_nr(this); 
                      ....
                  }	
              );
          }
        )(this_CtrlO);
        .....	
    };

 
Man beachte: Die “immediate function” wird im Kontext des vorliegenden Beispiels in der Initialisierungssfunktion “init_img_control” nur genau einmal ausgeführt.

Fazit

Über die Callback-Funktion, die innerhalb der “.each()”-Funktion für Selektionen zu definieren ist, lassen sich auch Methoden eines abstrakten Control Objects [CtrlO] zur Behandlung der selektierten HTML-Objekte aufrufen. Das gilt selbst dann, wenn die Selektion $(..).each( ..) innerhalb einer anderen
Methode desselben CtrlOs vorgenommen wird. Dem Kontextwechsel des this-Operators in den verschiedenen Code-Bereichen der Funktionen beugt man durch rechtzeitige Zwischenspeicherung in einer geeigneten lokalen Hilfsvariable im Scope der kapselnden Methode vor. Die this-Referenz auf das selektierte, aktuell zu behandelnde HTML-Objekt kann man den CtrlO-Methoden als Parameter übergeben. Damit können Aufgaben, die im Rahmen von .each() durchzuführen sind, vollständig an geeignete Methoden von Control Objects delegiert werden.

Viel Spaß weiterhin mit jQuery, Javascript und der Kapselung von Funktionalität in Objekt-Methoden.

Javascript: Einsatz des new-Operators mit Variablen und dynamischer Vorgabe der Konstruktorfunktion

In PHP gibt es die Möglichkeit, den “new” Operator mit einer Variablen zu kombinieren. Dies entspricht einer indirekten Adressierung des Konstruktors. Beispiel :

$ClassName = "Class_Test"; 
$Obj = new $ClassName( param1, param2, ...); 

 
Probiert man etwas Ähnliches unter Javascript, so erleidet man Schiffbruch. Der String-Wert einer Variablen wird vom “new” Operator nicht als Bezeichnung einer Konstruktorfunktion interpretiert.

Sieht man typische Webseiten oder auch Bücher nach der Verwendung des “new”-Operators durch, so wird nach dem “new”-Operator fast durchgehend die Benutzung eines Literals beschrieben, das dem Namen der definierten Funktion entspricht:

function meterpreter() {
	this.alpha = 5; 
}      
var Obj = new meterpreter(); 
echo "value of property alpha = " +  Obj.alpha;    

 
Die Verwendung eines Literals scheint eine indirekte, dynamische Adressierung auszuschließen.

Nun passiert es einem aber auch unter Javascript, dass man ein Objekt gerne aus einem dynamischen Kontext heraus erzeugen möchte. Dann will man den “new”-Operator mit einer Variablen kombinieren, die dynamisch ermittelt wurde, und deren Wert irgendwie die Konstruktorfunktion referenzieren soll. Ein Beispiel:

Man möchte beim Startup einer Webseite eine Reihe von (Singleton-) Objekten erzeugen. Die Namen der zugehörigen
Konstruktorfunktionen seien in einem Array gespeichert. Ein Loop über das Array könnte die Objekterzeugung durchführen, wenn der “new”-Operator mit dem jeweiligen Array-Eintrags verbunden werden könnte und dadurch dann indirekt auch der jeweils benötigte der Konstruktor aufgerufen werden würde. Wie also nutzt man den “new”-Operator zusammen mit Variablen unter JS?

Hier hilft es, sich daran zu erinnern, dass definierte JS-Funktionen Objekten entsprechen, die sich Variablen zuordnen lassen. Nehmen wir in Anlehnung an das obere Beispiel an, wir hätten ein globales Objekt definiert, dass wir GOC (Global Object Controller) nennen wollen und das ein Array mit Namen für potentielle (Singleton-) Objekte beinhaltet. Nehmen wir ferner an, dass wir zugehörige Konstruktorfunktionen bestimmten Variablen des GOC mit normierten Namen zugeordnet hätten:

this.GOC = new Global_Object_Controller();  
this.GOC.createObjects(); // hier konstruieren wie Objekte als Elemente des GOC

function Global_Object_Controller() {
	this.ay_ctrl_obj_names  = new Array('Gallery', 'Ajax', ....);
	this.num_ctrl_objs = this.ay_obj_names.length;

	// Konstruktor Definition
	// ----------------------- 
	this.Constr_Gallery = function( param ) {
	 	.....	
		this.alpha = param + 1; 
		.....
		.....
 	};

	// Method definition of Constr_Gallery 
	// Wir verwenden zur Abwechslung mal die an Arrays angelehnte Notation ...
	this['Constr_Gallery'].prototype.do_something = function() {
		...
		this.obj_num += 10; 
		...
	};  
	.....
	..... 	

	// Konstruktor Definition
	// ----------------------- 
	this.Constr_Ajax = function( param ) {
	 	.....	
		this.obj_num = param + 1; 
		.....
		.....
 	};
	....
	....
}

 
Dann können wir z.B. über eine Methode tatsächlich Objekte dynamisch erzeugen lassen – und zwar z.B. über folgenden simplen Trick:

Global_Object_Controller.prototype.createObjects = function() {
	
	var ctrl_obj_name = ''; 
	var constr_name = ''; 
	....
	for (i=0; i<this.num_ctrl_objs; 
i++) {
		...
		ctrl_obj_name = "Obj_" + this.ay_ctrl_obj_names[i]; 
 		constr_name   = "Constr_" + this.ay_ctrl_obj_names[i];

		// Indirekter Aufruf des Konstruktors über eine Variable (hier des GOC)  
		// *******************************************************************
		this[ctrl_obj_name]  = new this[constr_name](i); 
		// ******************************************************************** 		
		// ist identisch mit 
		// window.GOC[ctrl_obj_name] = new window.GOC[constr_name](i); 		
	
		// console.log("Objekt " + ctrl_obj_name + " im GOC kreiert");  
  		....
	}	
	.....
	// console.log("Obj_Gallery.obj_num = " + this["Obj_Gallery"].obj_num ); // value=1 
	this["Obj_Gallery"].do_something(); 
	// console.log("Obj_Gallery.obj_num = " + this["Obj_Gallery"].obj_num ); // value=11  
	// console.log("Obj_Ajax.obj_num = "    + this["Obj_Ajax"].obj_num );    // value=2  
	
	.....
};   

 
Das funktioniert! Man erkennt, dass in unserem sehr simplen Beispiel die gewünschten Objekte über Variablenaufrufe als Elemente des GOC-Objekts erzeugt werden.

Man kann den “new”-Operator also tatsächlich mit Variablen (irgendwelcher Objekte oder von “window”) kombinieren, wenn diesen Variablen bereits sinnvolle Konstruktorfunktionen zugeordnet wurden. Das erinnert an den Callback-Mechanismus – hier allerdings für den “new”-Operator.

Die indirekte Adressierung erfolgt im Gegensatz zu PHP dadurch, dass man den “Namen” der Variablen im Zuge des Algorithmus dynamisch festlegt und darüber dann auf den Konstruktor als das Funktions-Objekt referenziert. Das erfordert zwar ein etwas anderes Vorgehen, schränkt einen aber im Vergleich zu PHP in der Zielerreichung einer dynamischen und indirekten Konstruktor-Referenzierung nicht ein.

Dadurch wird man bzgl. der Objektgenerierung sehr viel flexibler, als wenn man sich immer mit Literalen herumschlagen müsste.

Off Topic:

Das Beispiel zeigt übrigens, dass Konstruktorfunktionen nicht immer zwingend im globalen Kontext (window) platziert werden müssen. Sie können auch jederzeit Variablen eines bereits definierten übergeordneten Objekts (oder seines Konstruktors) zugeordnet werden. Dies eröffnet in bestimmten Fällen weitere Möglichkeiten der Kapselung von Code.
In der Praxis muss man sich eine Zuordnung von Konstruktor-Funktionen zu Variablen aber gut überlegen. Schon aus Gründen der Codeverwaltung wird man Konstruktorfunktionen für wichtige Objekt in separaten, eigenen Dateien aufbewahren. Beim Laden der Dateien werden die Funktionen dann typischerweise in den globalen Kontext platziert.
Zudem gilt: In komplexen Codes, die z.B. mit Eclipse oder anderen Tools gewartet werden, ist die Zuordnung von Konstruktorfunktionen zu Variablen eines anderen Konstruktors möglicherweise mit dem Nachteil verbunden, dass Code-Outliner diese Sub-Konstruktoren, zugehörige Variable und Funktionen ggf. nicht mehr als eigene Objekte ausweisen – sie sind dann einer einfachen Navigation im Code über den Outliner nicht mehr zugänglich.

Will man die Konstruktoren deshalb aus guten Gründen unabhängig von anderen Objektbeschreibungen definieren, so ist das Codebeispiel leicht zu modifizieren: Man definiert die Konstruktorfunktionen global und nicht im GOC. Und ruft sie dann im GOC und dessen Loop wie folgt auf:

this[ctrl_obj_name] = new window[constr_name](i);

Viel Spaß weiterhin mit Javascript!