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 »

18.4.2011 von rmo.

Unter Opensuse 11.4 ist der Firefox 4 Standard. Ich habe - wie immer schon - die 64 Bit Variante des Betriebssystems und des Firefox installiert. Zudem läuft KDE 4.6.2.

Nun denkt man so, dass der von Suse als RPM ausgelieferte aktuelle Flashplayer 10.2 in der 32Bit-Variante über den üblichen “nspluginwrapper”-Mechanismus mit Firefox 4 (64 Bi) vernünftig zusammenarbeiten würde. Schießlich ging das mit Firefox 3.6.16 (64 bit) unter Opensuse 11.3 ja auch problemfrei !

Beim Firefox 4 (64 Bit) ist dem leider nicht so! Komplexe Flash-Filme oder sogar Adobe eigene Flashelemente (etwa die Audio oder Video-Player) werden häufig durch Darstellungsfehler so entstellt, dass es keinen Spaß mehr macht, Flash-Seiten anzusehen. Fehler über Fehler ! Man fragt sich, ob das jemals vernünftig getestet wurde ….

In meiner Not habe ich dann mal wieder nach einer halbwegs aktuellen 64Bit -Variante des Flash-Players für Linux umgesehen. Damit habe ich früher schon ganz gute Erfahrungen gemacht. Fündig wird man zur Zeit unter

http://labs.adobe.com/technologies/flashplayer10/square/

Ich habe mir dort die aktuelle Version heruntergeladen. Zur Installation der “libflashplayer.so”-Datei unter Opnsuse sehen Sie bitte folgenden früheren Beitrag:

http://linux-blog.anracom.com/2009/01/26/kurztest-der-64-bit-version-des-flash-plugins-von-adobe/

Bitte nicht die vorher notwendige Deinstallation des “nspluginwrapper” vergessen.

Das Ergebnis des Tests der 64-Bit-Variante: Das allermeiste an Flash-Seiten wird richtiger und schneller dargestellt als mit der für 64-bit Linux und 64-Bit Firefox 4 völlig ungeeigneten offiziellen 32Bit-Variante des Players.

Bleibt erneut die Frage offen: Wann sehen die verantwortlichen bei Adobe endlich ein, dass sie für Linux eine vernünftige “offizielle” 64Bit-Unterstützung bieten müssen?

Geschrieben in Web - Browser und Co., LAMP / Webentwicklung, Erfahrungsberichte | 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 »