30.7.2011 von rmo.

Da es z.Z. kein Paket gibt, dass einem eine direkte Installation einer PHP-Entwicklungsumgebung unter dem neuen Eclipse “Indigo” ermöglichen würde, ist ein wenig Handarbeit erforderlich.

Ich beziehe mich nachfolgend auf die Hinweise von “aaronbonner” auf der Webseite http://aaronbonner.tumblr.com/post/6035060125/installing-pdt-3-on-eclipse-3-7-indigo.

Die aktuelle Eclipse-Indigo-Version holt man sich von http://www.eclipse.org/downloads/.

Dort lädt man sich das Paket “Eclipse Classic 3.7″ (in meinem Fall für 64Bit Linux) herunter und “installiert” das Paket in seinem Wunschverzeichnis durch entsprechendes Expandieren des Tar-Balls (z.B. mit ark).

Nun gilt es zunächst, Eclipse die erforderlichen Update-Sites bekannt zu machen. Wir wechseln daher über den Menüpunkt

“Help >> Install New Software … ”

auf die Seite “Available Software”. Hier klicken wir auf den Link “Available Software Sites” und fügen folgende Repository-Sites hinzu:

• Indigo >> “http://download.eclipse.org/releases/indigo”
• The Eclipse Project Updates >> “The Eclipse Project Updates”
• PDT 3.0 Update Site >> “http://download.eclipse.org/tools/pdt/updates/3.0/milestones”
• Subversive Site >> “http://community.polarion.com/projects/subversive/download/eclipse/2.0/indigo-site/”
• Subversive Update Site >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
• Subversive Integrations >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
• Subversive SVN Connectors >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
• WTP-Patches >> “http://download.eclipse.org/webtools/patches/drops/R3.1.2/P-3.1.2-20100413200422/repository/wtp-patches312-tests”

Wie man die Sites benennt, ist dabei jedem selber überlassen. Hauptsache die http-Adressen stimmen.

Danach installiert man sich die benötigten Pakete - in meinem Fall :

• Eclipse Web Developer Tools
• Eclipse XML Editors and Tools
• Eclipse XSL Developer Tools
• JavaScript Development Tools
• JAX-WS DOM Tools
• JAX-WS Tools
• Native JavaHL 1.5 Implementation
• Native JavaHL 1.6 Implementation
• PHP Development Tools (PDT) Runtime Feature
• PHP Development Tools (PDT) All-In-One SDK
• PHP Development Tools (PDT) SDK Feature
• PHP Development Tools (PDT) Source Feature
• Remote System Explorer End-User Runtime
• Subversion Revision graph
• Subversive SVN Connectors
• Subversive SVN JDT Ignoe Extensions
• Subversive SVN Team Provider
• Subversive SVN Team Provider Connectors Sources
• SVNKit 1.2.2
• SVNKit 1.3.3
• SVNKit 1.3.5
• Web Page Editor
• WST Server Adapters

• Axis2-Tools
• Dynamic Languages Toolkit - Mylyn Integration
• JST Server Adapters
• JST Server UI
• Mylyn Commons
• Mylyn Context Connector: Eclipse IDE
• Mylyn SDK
• Mylyn Task List
• Mylyn Task-Focused Interface
• PDT Mylyn Feature
• Subversive SVN Integration for the Mylyn Project
• Target Management Terminal

Am wichtigsten sind hier natürlich die PDT-Pakete. Für die SVN-Anbindung sind die Subversion-Pakete und Konnektoren wichtig. Wer Task-orientiert arbeiten will, sollte auf die Mylyn-Pakete zurückgreifen.

Viel Spass dann mit Eclipse Indigo und der zugehörigen PHP-Unterstützung !

Geschrieben in Eclipse für PHP-Projekte | Keine Kommentare »

13.7.2011 von rmo.

Muss nach einer längeren Pause mal wieder intensiv mit PHP entwickeln. Bei dieser Gelegenheit habe ich mich wirklich über einen größeren Bug in Eclipse Helios geärgert.

Das Problem unter Eclipse Helios

Dieser Bug betrifft das Editieren großer Dateien und gliedert sich eigentlich in 2 Teile:

• Die Reaktionsgeschwindigkeit des Editors beim Tippen nimmt mit zunehmender Größe der Dateien immer schneller ab. Die getippten Buchstaben erscheinen nur erheblich verzögert am Schirm. Oberhalb 5000 Zeilen pro Datei ist der Eclipse eigene PHP Editor nicht mehr zu gebrauchen.
• Parallel zum Tippen beginnt Eclipse offenbar den gesamten Code des Files auf potentielle Fehler zu untersuchen. Die CPU-Belastung ist hierbei enorm.

Leider kann man sich nicht immer aussuchen, wie groß die Dateien sind, mit denen man arbeiten muss. Und dann wird der Eclipse Editor unter Helios wirklich zu einer Arbeitsbehinderung.

Siehe hierzu auch https://bugs.eclipse.org/bugs/show_bug.cgi?id=326261. In den Beiträgen zum Bug wird als Zwischenlösung empfohlen, das Syntaxcoloring abzuschalten. Ferner gibt es einen etwas schwierig einzuspielenden Patch.

Lösung 1: Wechsel zu Eclipse Indigo

Ich habe gestern auf meinem Laptop die neue Eclipse Version Indigo installiert. Nach einem Tag intensiver Arbeit kann ich diesen Schritt jedem empfehlen, der von dem beschriebenen Problem betroffen ist. Unter Indigo ist der erste der beiden Punkte tatsächlich behoben. Man kann auch bei relativ großen Dateien wieder fließend tippen.

Allerdings folgt auf das Editieren weiterhin eine längere Orgie der Dateianalyse mit sehr hoher CPU-Belastung. Wohl dem, der hier mehrere CPU-Cores zur Verfügung hat.

Wie ich von Helios zu Indigo übergegangen bin, beschreibe ich in einem nachfolgenden Artikel.

Lösung 2: Kompaktere Codes - kompaktere Klassen

Ein Gutes hat der “Bug” ja vielleicht: Um die Code-Dateien zu verkleinern, beginnt man immer öfter, über den Aufbau und die Struktur der eigenen Klassen nachzudenken.

Ich habe jedenfalls bei meinen eigenen Klassen, in denen sich über die Jahre hinweg immer mehr Methoden angesammelt haben, begonnen, bestimmte Variablen bzw. Methoden besser zu gruppieren, in separate Repräsentations- und Funktionalklassen zu bündeln und dann auszulagern. Bei Bedarf instanziiert die ursprüngliche Klasse dann entsprechende Objekte. Hierzu gibt es je nach Situation mehrere brauchbare Entwurfsmuster.

Eine einfache Variante, die die Struktur der wachsenden Klassen weitgehend aufrechterhält, ist die Delegation der Aufgabe in der Form, dass man die bisherige Methode in der Hauptklasse belässt, aber die Aufgabe selbst auf den Aufruf eines Funktionalklassen-Objekts und dessen entsprechende Methode verschiebt. Die zu manipulierenden Variablen werden dabei ggf. von der ursprünglichen Hauptklasse selbst wiederum als Objekt übergeben. Da diese Übergabe immer “by reference” geschieht, wird der Bedarf an Speicher nicht wesentlich erhöht. Die Klassen-Codes werden bei einem solchen Vorgehen i.d.R. sehr viel kompakter.

Denen, die sich mit Entwurfsmustern intensiv beschäftigen möchten, sei bei dieser Gelegenheit übrigens das Buch “PHP Design Patterns” von Stephan Schmidt (http://www.phpdesignpatterns.de/auflage-2/#buch) allerwärmstens empfohlen. Ich jedenfalls entdecke immer wieder neue “Offenbarungen” in diesem Buch.

Ein anderer Weg zu überschaubaren Dateien führt ggf. über eine klarere Unterteilung der Vererbungshierarchie.

Content Assistance bei verteiltem Code

In beiden Fällen ist es bzgl. der Unterstützung (Content Assistance) beim Coding sinnvoll, sich im Editor auch Variable aus anderen Dateien vorschlagen zu lassen. Hierzu muss amn den entsprechenden Haken unter dem Menüpunkt

"Window >> Preferences >> PHP >> Editor >> Content Assist >> Show Variables from other files"

setzen.

.

Geschrieben in Eclipse für PHP-Projekte | Keine Kommentare »

31.3.2011 von rmo.

Ein kleiner Tipp zur Autocompletion unter Eclipse für PHP:

Heute hatte ich mal wieder das Problem, dass beim Editieren einer Datei mit einer PHP-Klasse die “Autocompletion” mit dem zugehörigen Proposal-Fenster nicht funktionierte. Obwohl ich meterweise Variable und Funktionen für die Klasse definiert hatte, kam nach Eingabe von “$this->” keine Vorschlagsliste hoch.

Das entsprechende Popup zeigte traurigerweise immer nur “No default proposals”.

Das geschah interessanterweise jedoch nicht in anderen Projekten und auch nicht in anderen Verzeichnissen des aktuell von mir bearbeiteten Projekts.

Was war also die Ursache? Letztlich ganz einfach:

Die Datei, an der ich arbeitete, lag in einem Verzeichnis, der nicht in den Build-Pfad des Projektes integriert war. Dies wiederum lag daran, dass ich einen ganzen Verzeichniszweig nachträglich per Verzeichnisbrowser (Dolphin) in mein Projekt eingefügt hatte. Ich hatte die neuen Verzeichnisse also nicht mit Mitteln von Eclipse “importiert”.

Eclipse erkennt dann zwar beim nächsten Öffnen die neuen Dateien und markiert diese im PHP-Explorer auch mit einem Fragezeichen. (Ich hatte das “?” rechts unten am Verzeichnis- oder Datei-Namen bislang auf das SVN-Repository bezogen, das ich dem Projekt zugeordnet hatte, und vermutet, dass das “?” anzeigt, dass die Zuordnung des Verzwichnisszweiges und seiner Dateien zum SVN-Repository unklar ist.)

Aber wer meint, dass ein SVN-Commit oder eine Validierung oder ein Export in ein Remote-Filesystem unter Eclipse dazu führen würde, dass der neue Verzeichnis-Zweig mit all seinen Unterverzeichnissen und Dateien automatisch in den Build-Pfad des Projektes aufgenommen würde, der täuscht sich. Dies muss man im hiergegeben Fall einer Verzeichnismodifikation außerhalb der Eclipse-Tools vielmehr selbst erledigen.

Welche Verzeichnisse bereits im Build-Pfad berücksichtigt werden oder eben nicht, erkennt man über das Konfigurationsfenster zum “PHP Build Path”. Das öffnet man entweder über den Menüpunkt

Project >> Properties >> PHP Build Path

oder über das Kontextmenü des Projektes :

Klick mit RMT auf das Projekt im PHP-Explorer >> Build Path >> Configure Build Path >> PHP Build Path

(RMT: Rechte Maus-Taste).

Hier kann man die fehlenden Verzeichnisse zum PHP Build Path explizit hinzufügen.

Ein Klick auf den “OK”-Button löst dann einen neuen Lauf der DLTK-Indizierung unter Eclipse aus. Danach funktioniert dann auch der Proposal-Mechanismus für die Autocompletion beim Editieren des Codes wieder.

Geschrieben in Eclipse für PHP-Projekte, LAMP / Webentwicklung | Keine Kommentare »