Category Archives: Eclipse für PHP

Beiträge zum Einsatz von Eclipse in der PHP-Web-Entwicklung

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

Posted on by

Some time ago I wrote a blog post about the still unsatisfactory Javascript support by the JSDT plugin for Eclipse – at that time for “Eclipse Neon R”. See:
Eclipse Neon 1 – Standard-JSDT mit Schwächen – zusätzliche Plugins

I can very well imagine how difficult it must be to create a new and better basis for JSDT. In addition there may be general limitations imposed by the Eclipse Neon platform itself. However, this kind of awareness won’t help me much as a web developer who needs or at least wants to use Eclipse Neon 2 or 3 for Javascript projects or PHP projects with Ajax/Ajaj clients.

In particular, I did and do not like the present limitations of the JSDT Outline View. I shall describe some of these deficits only briefly below. Anyone who recently used Eclipse Neon for Javascript development knows what I am talking about.

The Eclipse plugin Webclipse JSjet offered by the US company Genuitec (in combination with Tern) helps to overcome some of these deficits. So, I found it interesting to try using JSjet within Eclipse Neon 2 in a real project I am presently working on. Instead of going back to Eclipse Mars …

At first I was very happy to get more information in the Outline view than with JSDT when coding Javascript objects and methods. Compared with Neon’s JSDT it felt like a big step forward. However, not all that shines is real gold. So, in a second round of testing I looked a bit closer at code analysis capabilities of JSjet/Tern. And already with a relatively small test file I found some problematic aspects of the JSjet Outline information presented for object oriented Javascript code. This is the topic of a second post coming soon.

In addition I must say, that JSjet is not for free – at least not for a reasonable amount of development work per month. And ordering a license comes with a – in my opinion – strong negative side aspect – which I do not like at all. It has to do with the automatic and periodic information transfer to the company behind JSjet. This is the topic of a third post.

Deficits of the Outline View information presented by JSDT for Neon 2

JSDT supports ES6 and ES2015 – at least as far as I have tested. But for conventional prototype based object and inheritance structures the JSDT Outline View was/is not of much practical use in Neon R or Neon 2. Reason: It did and does not show the full internal structure of Javascript functions, of constructor functions and their prototypes, of ES6 classes, of objects derived from constructor functions or classes or of objects in a prototype chain.

When testing “Neon R” I still hoped for an improvement in Eclipse Neon 2. Now I work with PHP on a Neon 2 and Neon 3 platform. But the JSDT Outliner has become even worse. An editorial of the company Genuitec – although cluttered with advertisement – rightly criticizes some major deficits of JSDT in Eclipse Neon; see: https://www.genuitec.com/boost-eclipse-neon-javascript-development-with-jsjet/. In my own words:

The present JSDT Outliner provides only some deeper information on classes and methods declared by the newer “class” statement of Ecmascript 6. However, even then we do not see properties (member variables) of a ES6 “class”. For constructor functions we cannot see see any deeper hierarchy structure at all – only the topmost class/function declaration itself. But no internal structure. E.g. no functions and , their prototype based “methods” (i.e. defined functions of the prototype)

So, no “methods” (i.e. functions of prototype objects) are listed in the Outliner. Tested on a freshly installed Neon 2. See below the very simple test code (really,
only for testing; I normally do avoid global variables … ).

Frankly, I think this is a bit of a mess; you may also note that the global variable “x”, which is not declared explicitly with a “var” or “let“ statement, does not appear at all in the JSDT Outliner.

You can’t work and navigate with such an Outliner in real world projects, especially when you do some more complex Ajax/Ajaj development ….. Also code changes show up in the JSDT Outliner only when and after a you explicitly save your JS file.

Probably, I am not the only one who has to support older Javascript modules based on the prototype declarations of objects and prototype based inheritance patterns. In times before and up to Eclipse Mars I used the Outliner a lot for navigation and quick oversight purposes. If you have more than just one object in a code and more than only a few methods your coding efficiency depends on a reasonable IDE functionality presenting the code structure and its hierarchy over a sufficient amount of hierarchy levels. The present JSDT does not help you much regarding this point.

Alternatives for JSDT? Webclipse JSjet?

So, I started to look for alternatives for or supplements to JSDT in Eclipse Neon. One could think about Aptana Studio. However, the Jenkins repository for Aptana 3.4.x on the Eclipse marketplace is presently not working (since midth of Feb 2017 by the way; due to license and legal aspects). And for the Aptana studio plugin for Eclipse I have always experienced some conflicts with other plugin packages and their editor components in the past. So, I tried some other things as e.g. Vjet, but nothing really convinced me.

Eventually, some weeks ago, I came across “Webclipse JSjet” of the US company Genuitec. Genuitec claims that JSjet provides significantly more information about the code and object structure than pure JSDT. Basically, this is true. However, not all and everything is satisfactory with the JSjet solution either. Below and in the forthcoming posts I discuss only some more or less obvious points regarding the Outline View – so this is not going to be an in depth review. But it may at least give other Eclipse users some orientation. However, and to be fair: There are more interesting JSjet/Webclipse features than covered in my small blog post series. And some of these features are really worth a closer look and some tests. One example is the support of Javascript code debugging.

JSjet and the Eclipse Outliner – What is good?

I should first of all mention the following 2 points – which are related to the presentation of the code hierarchy, objects and object elements in the Outliner:

  • Information about the code hierarchy structure and internals of constructor functions and classes
    JSjet provides you with information about all global variables and functions it finds during its analysis of your Javascript code. In contrast to JSDT, JSjet detects all global variables – whether they explicitly declared by “var” or “let” statements or not.

    Functions that are used as constructors in a “new” statement or functions with explicit prototype declarations are marked with a “P” for “prototype”. This is certainly helpful for a quick orientation.

    JSjet provides you with information about general objects (e.g. declared by using literals). It informs you about their member variables and their functions/methods – i.e. you get an overview over the first inner hierarchy level of objects. (For comparison: The present PHP Outliner of PDT does not
    provide you with more hierarchy levels.)

    Because a function is an object itself in Javascript you expect an overview about the elements of any constructor function and its prototype, too. And yes, JSjet provides you with information gathered about elements of a constructor functions and their prototype.

    For concrete objects derived from a constructor function, only the relation with the constructor and its prototype is indicated in the Outline View. This also works for objects defined via simple inheritance patterns using a prototype chain. In most cases this is sufficient – as you can look up inherited properties in the displayed structure of the constructor. (The interesting question, how changes of properties applied for object instances or extensions of concrete object instances with additional properties or methods are handled, will be discussed in the forthcoming post.)

    For arrays you get an oversight over the different types of the array’s elements. See the test example of my next post for a display of this property of JSjet.

    By the way: The same depth of information is provided by the “Quick Outliner” which one can activate by pressing “Ctrl O” or via opening a context menu point after a “right mouse click” on a code element.

  • Project wide or local code analysis of the present file via “Tern”
    When you install JSjet some more Eclipse plugin modules from the French “Tern” project are installed. Tern itself uses a local “node.js”-installation provided automatically in your home directory under the subdirectory “~/.webclipse”. The basic task of Tern is a project wide code analysis.

    In the “preferences” settings for “Javascript” new menu points for the Tern configuration appear; in addition you will find a point named “Performance”. It gives you a dialog where you can set the scope, quality and performance of the Tern-based analysis.

    The default for the scope is “Entire project“. For this setting you will e.g. notice that that e.g. (global) variables or functions previously defined in some other files of your project are NOT shown in the Outliner. You may get more information about missing points and their location via an additional context feature, namely the “Call Hierarchy“.

    In the beginning I found this type of analysis and display a bit confusing. Meanwhile, I consider it helpful because it forces you to watch your naming of variables, objects, functions, prototypes and to think about the proper use of namespaces or modules.

    On the other side: If you want to keep several versions of a Javascript-file inside one and the same project folder structure the Tern analysis may lead to trouble and misunderstandings. In such cases the Tern scope can be reduced to the “Current File“. However, just switching via Eclipses’s preferences won’t always make this change work at once. Probably due to caching. Most of the time, however, I got success with closing all js-files and opening them again.

  • Availability of information on variables, functions, objects, prototypes in the code completion dialog Knowledge which the duo JSjet/Tern has gathered on global variables, functions, constructor functions, elements of prototypes and classes is also made available in the code completion dialog window. This helps a lot when coding – at least theoretically (see, however, the next post!).

The analysis of a realistic Javascript code example with several objects included, therefore, provides a sufficient amount of information to get an overview and to support navigation throughout the code. See the following picture:

So – this looks good on a first glimpse. A deeper analysis
is the topic of the next blog post. With ambivalent results …

JSjet and the Outliner – what is missing?

There are more things which felt not satisfactory when testing JSjet. There are some obvious deficits, which you find very quickly when doing real work with it.

  • No display of “private” variables
    As will be discussed in more detail in the next post, no private variables defined either with the old “var” or the new “let” statements inside functions, constructor functions, closures or class methods are shown. This is really a pity! One would like to now what a developer wanted/wants to keep private in a piece of code. Especially, if you work with code not designd by yourself.

    However, private variables defined inside functions or object methods do appear in the code completion dialog! But using it you may get confused, if there exists a global variable with the same name as a variable declared for the present function scope! The code completion window of JSjet will not make a clear distinction between these two different variables. The variable name will only be referenced once – and the only hint you get is its general occurrence in the code file. We shall see more on this topic in the next blog post.

  • Missing shortcut icons and control actions for the Outline view
    Another missing feature is a collection of shortcut icons at the top of the Outline View for useful operations like a simple full collapse of the code hierarchy structure. Instead the icon area at the top of the JSjet Outline view is extremely reduced in comparison to the standard one for JSDT.

    You start missing an overall collapse option as soon as you have real life and complicated code structures. JSjet opens the Outline View in a mode where the all hierarchy levels of constructor functions and classes are displayed fully expanded. So you must collapse object for object and hierarchy level for hierarchy level by yourself.

    In addition there is no option to set on/off a link to the editor actions. JSjet is automatically linked to the editor – which is not always desirable.

  • No filter options for the Outline View
    The worst deficit in my opinion is the lack of filters – in the sense of e.g. “show only objects”, “show functions only”, “do not show variables”, … . Just to avoid clattering of the Outline view with presently uninteresting things during the development of longer, complex programs.

Most of these points were working at last in old versions of JSDT (Kepler, Mars).

Are there usage problems?

Yes, I experienced that the outliner did not always give me complete information on objects – even when reducing Tern’s scope to the present file. This tends to happen sometimes after having used the “hierarchy call” feature of Eclipse JSDT, sometimes after a long time doing nothing on a project in the same workspace or after having worked on another project in the same workspace. It also happens when you switch the Tern analysis scope. …. or when you work with 2 eclipse windows …. It is unclear to me, what the real cause is – but it happened a few times with Eclipse 2. Maybe computing the Outline contents is not triggered correctly under some circumstances. The behavior became better after a recent update to Neon 3 and setting the Tern settings to quality instead of performance. In most cases closing all “.js” files and opening them again helped.

First conclusion

JSjet and Tern overcome the problem of JSDT which provides too few information in the Eclipse Neon Outline view. From JSjet you get sufficient information for keeping an overview over your code and object structure and for navigating between functions, prototypes and derived objects.

However, after some real work with JSjet/Tern I got a bit confused about some hints in the Outliner which
seemed to be at least misleading. So, I decided to test the code analysis of JSjet roughly. And this led to the question :

Is all of the information provided by JSjet in the Outline view really valid?

See the next blog post
Webclipse JSjet, Eclipse Neon 2 and the Outline View – what I like and what not – part II
for the results!

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

Posted on by

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

Hilfreiches Eclipse Plugin: wtp-webresources

Posted on by

Ich versuche ja gerade, meine Frau dazu zu bringen, statt des proprietären und nicht linux-tauglichen und wenig stabilen Dreamweavers die IDE Elipse für HTML und CSS Coding zu benutzen. Zur Auswahl stehen dort die Web Standard Tools (WST) oder z.B. das Aptana Studio Plugin. Nun zieht die Installation des Aptana Plugins immer noch einige unangenehme Nebeneffekte nach sich, so dass man sich lieber mit den Editoren der nativen Eclipse Web Developer Tools begnügen möchte.

Ein Nachteil des WST Eclipse HTML Editors für Eclipse-Umsteiger ist u.a. folgender:

Man erhält zwar Code Assist Vorschläge bzgl. elementarer CSS2- oder CSS3-Anweisungen für Inline-Styles. Beim Editieren des “class”-Attributs eines HTML-Tags erhält man jedoch keine Assist-Angebote zu bereits definierten Style-Anweisungen für Classes, die in CSS-Dateien eines Eclipse-Projekts enthalten sind – auch dann nicht, wenn man solche CSS-Dateien bereits explizit im HEAD-Bereich der HTML-Datei eingebunden hat. Umgekehrt erhält man bei einem Hover über die Klassendeklaration eines HTML-Tags keine Informationen zu den zugehörigen Style-Festlegungen.

Ähnliche Defizite gibt es im Bereich der Ergänzung von Bild-, CSS-File- und JS-File-Ressourcen. Hier ließen sich Content Assist Angebote ja prinzipiell über die Inhalte der Projektverzeichnisse zusammenstellen.

Das Plugin “wtp-webresources” behebt all diese Schwächen und ist damit ein wirklich nützliches, empfehlenswertes Helferlein für Eclipse Mars. Siehe:
https://github.com/angelozerr/eclipse-wtp-webresources

Ob das meine Frau überzeugen wird, weiß ich noch nicht – der nächste Punkt, den sie im Vergleich mit Dreamweaver mit Sicherheit vermissen wird, ist eine Darstellung der effektiv wirksamen CSS-Styles für ein HTML-Tag aus der Kombination der für das Tag festgelegten “id”-bezogenen, “class”-bezogenen Styles, aktuellen Inline-Styles und zugehöriger Spezifizitätsregeln. Wäre auch in Eclipse nützlich ….