Category Archives: Eclipse für PHP

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

PHP Code Content Assists und Inline Type Hinting in Eclipse

Posted on by

Vor ein paar Jahren war ich sehr happy, als ich entdeckte, dass Eclipse mit dem PHP Pluging (PDT) etliche Möglichkeiten im Bereich des PHP Content Assistings bietet. So nutze ich die Möglichkeiten des Type Hintings mittels “phpDocumentor tags” ausgiebig oberhalb der Deklaration von Class Member Variablen oder bei der Definition von Funktionen (frei oder als Objekt-Methoden). Es ist einfach schön, bequem und sehr effizient, wenn “Ctrl-Space” das Tippen von neuem Code in einem PHP-Projekt mit passenden Vorschlägen aufgrund der Definition von Klassen etc. in anderen Dateien unterstützt. Fast magisch !

Was ich bisher nicht hinbekommen hatte, war das Type Hinting und “Content Assisting” zu Variablen im PHP-Code, die im Rahmen einer dynamischen Namensgebung über die Nutzung der Funktion “call_user_func” als Objekt einer Klasse instanziiert werden. Das braucht man z.B., wenn man das Singleton-Pattern benutzt und das Singleton-Objekt entweder erstmalig instanziiert werden muss oder aber die Referenz auf das ggf. schon existierende Singleton-Objekt geholt werden soll – soweit es bereits woanders instanziiert wurde.

Aber auch das geht unter Eclipse PDT mit sog. “Inline Type Hinting”. Ein Beispiel: 

	$get_instance ="getInstance"; 
	$Class_SS_Run_Data_Name = "Class_SS_Run_Data";
	$ay_SS_Run_Data		= array($Class_SS_Run_Data_Name, $get_instance);

	/* @var $SS_Run_Data Class_SS_Run_Data */		
	$SS_Run_Data = call_user_func($ay_SS_Run_Data);
	unset($ay_SS_Run_Data);

getInstance ist hier eine statische Methode, die gemäß des Singleton Patterns entweder das Objekt instanziiert oder die Referenz auf das Singleton Objekt aus einer statischen Variablen ermittelt.

Wichtig ist hier aber die Kommentar-Zeile und ihr Aufbau. Die Klasse “Class_SS_Run_Data” ist in einer anderen Datei definiert, deren Source Pfad natürlich im Bereich des BUILD Path des PHP-Projektes liegen muss.

Tippe ich nun später “$SS_Run_Data->” im Code erhalte ich je nach Einstellungen des Content Assistings umgehend oder spätestens über Ctrl-Space eine Vorschlagsliste zu Variablen oder Methoden der Klasse. Super !

Gelernt habe ich das nach Lesen eines Artikels von Norm McGarry, der sich mal die Mühe gemacht hat, die verschiedenen Arten des “Type Hintings” für “Content Assist”-Zwecke unter Eclipse PDT zusammenzustellen. Siehe:
PHP Type Hinting with Eclipse

Herzlichen Dank an Norm McGarry!

Eclipse Luna, SVN – problem with older Subversion 1.6 repositories !

Posted on by

In Eclipse I have to handle a variety of PHP projects (with additional natures) which are interconnected in different ways. E.g. my present project may for convenience have links to folders of another project in another Eclipse workspace. Such links exist in my case for example to files containing very basic classes of some of my own frameworks. In some projects I combine the present project work with upgrading the basic framework classes in parallel to a new level of capabilities. In such a situation I want to directly change the basic classes for all other projects that use them and test compatibility aspects.

The version control of almost all interconnected projects is done by Eclipse Subversive plug-ins from Polarion. The link situation on the folder/file side of my projects leads to so called external SVN relations on the SVN side of my interconnected projects. These relations are generated automatically by the Subversive plug-ins for Eclipse.

In some cases I may even have different SVN locations – some local, some on a dedicated SVN servers in the local network or on the Internet. Unfortunately, not all of my SVN repositories are of the same Subversion version – which was no problem as long as different connectors were available in Eclipse and the repositories were generated to be backward compatible. Some of my SVN repositories are relatively old ones – i.e. of SVN version 1.6. Mostly associated with framework classes I continuously have worked on for years.

From KDE’s SVN client “kdesvn” I am very familiar with the problem that e.g. a client for a Subversion version 1.8 is not able to deal with SVN repositories that were generated with an older version of Subversion (e.g. Subversion version 1.6). An error message including as “… working copy is too old …. “ is a typical indication of this situation. In this case it does not help that you may have set up the repository with backward compatibility (e.g. to SVN version below 1.6). You have to update your repository by using the command

svnadmin upgrade

inside the base directory of the repository. Which may be delicate – if you did not set up any backward compatibility your Eclipse plug-in may no longer be able to handle the repository.

So, before updating SVN in your Linux OS and upgrading your SVN repositories you should always check carefully, whether the Subversive SVN plug-ins in Eclipse will be able to handle the repository afterwards. Actually, already this type of problem indicates that a strategy to maintain SVN repository versions consistently should be followed. However, I am a bit lazy. And as long everything worked smoothly I had no reason to upgrade my SVN repositories to one and the same Subversion version.

Some days ago – due to some irritating errors of syntax highlighting in the Kepler JSDT module – I installed Eclipse LUNA (i.e. version 4.4.2.) instead of KEPLER. The JSDT highlighting error went away. However, I ran into deep trouble with the subversion plug-ins.

Actually, my Eclipse upgrade lead to a complete mess because of my laziness in the past to keep the different Subversion versions of SVN repositories on the same level. The following discussion may help others to recover from such a situation and reconsider a strategy to keep the Subversion versions of one’s SVN repositories consistently aligned.

Eclipse Subversive plug-ins for LUNA provide SVN Connector Kits for Subversion versions 1.7 and 1.8, only

Recently, I had started with a new PHP project in Eclipse KEPLER depending on a set of classes of one of my frameworks. So, I thought this project would be a good choice to get some experience with Luna. Without much thinking I had installed several Eclipse plugins I typically use into LUNA as PDT, WST, Mylyn, JSDT
Jquery , etc. and of course Subversion and Polarion Subversive SVN Connector Kits. So, I felt well prepared to open the my Kepler workspace with Luna.

The first thing you may stumble across when using Luna first time is that you should make a copy of your original PHP projects in the Kepler workspace directory. Luna will upgrade your Kepler project in a way that is not backward compatible to older Eclipse versions. Ok, that done, I wanted to share my upgraded project by using a SVN repository. I chose an existing local SVN location – based on the “file” sub protocol of SVN. Then I started to check in the directories and files of my project. The check in process seemed to work well in the beginning. But then I was bombarded with error messages. Besides other things the messages told me that subversion stumbled across an “unsupported working copy”.

Ok, I checked the installed connector versions of the SVN Polarion plug-ins and did additional research on the Internet – the connectors were for Subversion version 1.7 and 1.8, only! Others are not available for Luna! As I did not remember exactly the version of my local repository (probably 1.6) I disconnected the PHP project from SVN with allowing to delete all SVN information from disk.

Making a new repository for your present project may not help

Next thought: Well, lets make a new SVN repository then – of SVN version 1.8. I combined this step with setting up a local lightweight SVN server – because somebody had told me that the performance of the core SVN protocol would be much better than the “file” protocol. After the intermezzo of the server setup I manually created a new SVN database on my local SVN server (i.e. my workstation). As Subversion on the Linux workstation is of version 1.8 -I had no doubts that LUNA now should be able to work together with this SVN database. From Eclipse I shared my previously disconnected project by using the new SVN location with the generic “svn//” protocol. And started to check in again. Which started well and then ran into errors again … 🙁

To analyze what happened I set up a fresh independent project and filled it with some directories and files and tested SVN transactions with my version 1.8 SV repository. That worked perfectly! So, something obviously was wrong with my other more complicated project. A closer analysis showed what the reader may already have guessed:

The errors occurred during the check in process when directories were reached that were linked to my basic long term projects with their old repositories. Which on the SVN side are located in an “external” repository. So, my conclusion was:

One must first remedy the outdated working copy situation for the basic projects which your present project may depend on by links. Their (external) SVN repositories have to be upgraded first.

In complicated dependency situations you may run into more problems

Although the above conclusion is correct it may not directly lead to success. By walking through my projects and trying to get them working again with SVN under LUNA I stumbled across several situations which stressed my nerves. Among others there are 2 stupid things that may lead you to dead end situations and prevent a recovery from them with the Eclipse subversion tools:

  • After a trial to check in files into (too old) repositories there may be open outgoing SVN transactions left which cannot be resolved due to the impossibility to handle old SVN working copies of connected projects with linked folders. You are forced to completely disconnect your present project from the SVN repository with a deletion of all SVN information from disk (i.e. “.svn” files in the folders and sub folders of your Eclipse project)
  • In complicated link situations you may find the following: There may be a mixture of “.svn” files in a project which describe the diverse repositories of linked folders of other projects on different version levels. I found that with the present plug-ins of LUNA this may lead to unrevoverable SVN situations and even repository corruption.
  • Despite disconnecting projects and allowing for a deletion of SVN information some “.svn” files may remain at unexpected locations. This may depend of what kind of SVN trouble and corruption you had and what you tried to remedy the situation. The remaining “.svn” files may include old SVN version information – leading to trouble again when you try to connect to an SVN repository next time.

Eventually, I gave up and really tried to build my previous Kepler projects from scratch again under Luna. Including the SVN aspects.

Steps to recover and get a working LUNA – SVN implementation again

The following sequence of steps worked in my case:

  • First, make copies of your projects AND the associated SVN repositories. You never know ….
  • Check in all files and directories in all of your projects with the old Eclipse version (in my case Kepler) to get the latest versions into the existing SVN repository.
  • If one of the previous SVN repositories used under Kepler is corrupted (according to SVN messages in Eclipse) – do not use it any longer in the steps below. Build a new repository location instead.
  • Disconnect all existing Kepler projects from SVN via the context menu of the project by using the menu points “Team >> Disconnect” and allow for a deletion of the SVN information from disk.
  • Important point: Remove all remaining “.svn” files inside your Eclipse projects which may have remained there by using the command
    “find . -name “.svn” -exec rm -fR {} \;”
  • Go to the SVN repositories that still worked in Kepler (wherever they may reside) and upgrade by “svnadmin upgrade” consistently to the present SVN version – in my case 1.8.
  • Systematically restore your basic projects – i.e. the ones on which other projects may depend – from scratch by using the upgraded repositories. Or share these projects again with reference to the upgraded repository from which you then update the files to the latest repository version.
  • If one of the last steps is not possible due to repository corruption you build up new projects in Eclipse and fill them with the files from your (Kepler) project backups. Then share them by using a new repository location of your choice. Check that all SVN transactions work as expected for your basic projects.
  • Only then rebuild your more complicated projects depending which depend on your basic projects and share them again with the upgraded SVN repositories or newly generated ones.

And in the future:

Follow a systematic approach to upgrade your SVN repositories consistently to Subversion versions your Eclipse installation AND your other tools of your Linux desktop can handle.

Finally: Have fun with Eclipse LUNA and PHP or JS/Ajax projects. It feels great so far ….

Kurzreview Eclipse 4.3 Kepler mit PDT und Aptana

Posted on by

Vor einiger Weile hatte ich mich wegen der miserablen Performance enttäuscht von Eclipse 4.2 Juno mit PDT abgewandt. Besonders bei Benutzung der neuen GTK-Oberfläche tauchten immer wieder lange andauernde 100%-Peaks in der CPU-Belastung von 1 bis 2 CPU-Cores auf. Auf meinem schwachbrüstigen Laptop eine Katastrophe – aber auch auf einem gut ausgestatten Desktop-Rechner eine echte Belastung.

Im besonderen galt dies beim Hin- und Herziehen von Tabs zwischen zwei getrennten parallelen, vertikalen Editor-Bereichen der GUI von Juno. Das Öffnen des Outline-Bereiches machte das System nochmal träger. Die parallel Sicht auf mehrere geöffnete Files sowie den Outline-Bereich benötige ich beim Arbeiten mit vielen Klassenbibliotheken aber immer wieder.

Es half keine Herumdoktern an den Speichereinstellungen für die JVM. Genausowenig half eine Umstellung auf die klassische Eclipse GUI. Daneben gab es auch immer wieder seltsame Probleme mit einer parallelen Installation von Aptana und PDT 3.1/3.2. Die Content Assist Vorschläge wurden entweder gar nicht oder nicht immer vollständig angezeigt. Die Schwierigkeiten waren sowohl bei Einsatz von Suns JVM für Java 7 als auch von OpenJDK 1.7 gegeben. Alles unter Opensuse 12.2 und 12.3 (64 Bit).

Für meine PHP-Entwicklungsarbeiten griff ich aus diesen Gründen bis gestern immer noch auf Eclipse 3.7 “Indigo” zurück.

Nun ist Eclipse in der Version 4.3 unter dem Namen “Kepler” erschienen. Daher habe ich gestern erneut einen Anlauf mit dieser aktuellen Eclipse-Version und dem zugehörigen PDT 3.2 plus Aptana Studio 3 unternommen. Und diesmal wurde ich nicht entäuscht:

Alles funktioniert wie es soll und das wirklich performant. Allerdings musste ich meine unter Indigo aufgebauten Workspaces unter Rückgriff auf vorhandene SVN-Repositories komplett neu aufbauen. Erst danach lief alle fehlerfrei.

eclipse_kepler_1_600

An den Standard Speichereinstellungen habe ich nichts verändert. Die “eclipse.ini” sieht daher wie folgt aus:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20130521-0416
-product
org.eclipse.epp.package.standard.product
–launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
–launcher.XXMaxPermSize
256m
–launcher.defaultAction
openFile
–launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

Es gab und gibt nach bislang 12 Stunden Arbeit keinerlei Hänger und keine Peaks in der CPU zu bemängeln! Das Arbeiten mit mehreren parallel angezeigten Editor- und GUI-Bereichen läuft sehr flüssig. Das Verschieben von Tabs für geöffnete Dateien zwischen zwei Darstellungsbereichen führt zwar zu einer kurzfristigen Belastung mehrerer CPU-Kerne – aber eben wirklich nur sehr kurzzeitig und das ist nicht als Bremse für das Arbeiten wahrnehmbar. Auch die Build-Operation für Projekte laufen mit angemessener Geschwindigkeit.

Aptana lässt sich parallel zu PDT einsetzen. Man kann zwischen den verschiedenen “Natures” entsprechend “facettierter” Projekte nach Lust und Laune hin- und herschalten. Die Content-Assists-Hinweise kommen entsprechend. Ich nutze z.T. den Aptana-Editor, um HTML-Code in TPL-Files für die Template-Engines Pear-ITX oder Smarty zu bearbeiten. Ich schätze dabei die browser-bezogenen Content Assist Hinweise. Aber auch der Wechsel zum normalen WST-HTML-Editor mit dessen Content-Assists-Fähigkeiten für HTML- und CSS-Vorschlägen klappt einwandfrei.

Aptanas PHP-Unterstützung benutze ich in der Regel nicht und
habe ich daher nicht wirklich getestet. Ein kurzes Umschalten auf die Aptana Editoren und Aptanas Content Assist für PHP zeigte mir aber keine unerwarteten Probleme.

Die SVN-Anbindung über Subversive und die Polarion-Konnektoren lief wie erwartet. Ein Gleiches gilt für MyLyn

Kurzum:
Für PHP-Projekte stellt Eclipse 4.3 “Kepler” endlich eine ernsthafte, weil funktionierende und performante “Eclipse 4.x”-Alternative zu Indigo dar. Ich kann den Umstieg wirklich empfehlen.

Ein kleiner Wermutstropfen
Schade irgendwie, dass es der HTML-“Web Page Editor” bisher nicht in die “WTP 3.5” -Repositories von Kepler geschafft zu haben scheint. Aber eine Installation aus den WTP 3.3.2 Ressourcen scheint keine größere Probleme zu machen.