One mans quest for a PHP IDE for Linux.

I'm sitting here staring at my favorite poster. It's a photo of a ship
that hit a reef and sunk long ago but still has its ass-end sticking
out of the water. The caption reads "It may be that your sole purpose
in life is to serve as a warning to others." (checkout despair.com for
more of these jewels.) That's how I feel right now after spending (or
rather EXpending) the entire day looking for a PHP IDE for my
mandrake linux box. All I wanted was an editor with highlighting that
would let me set breakpoints, step through my code, and watch
variables change ("... and memories of Turbo-Basic danced in their
heads.")

In a shameless effort to garner sympathy while warning others before
they take this journey, I thought I'd share my findings from the
field:

PHP plugin to eclipse:
cost: free.
relevant URLs: http://www.eclipse.org ,
http://phpeclipse.sourceforge.net/
Documentation: plenty for eclipse. none for the plugin.
Did it work?: almost.
Although the install directions were wrong, they weren't so wrong that
I couldn't figure out what to do. Afterwards I was able to start a PHP
project and edit a PHP file but I couldn't run it much less debug it.
All I got were error messages when I tried either. Another brain-dead
editor I dont need. Too bad since eclipse works fine for Java. Someday
this might be a viable option.

PHP-DBG with DDD (whilst in my BVDs):
relevant URLs: http://dd.cron.ru/dbg/ ,
http://www.gnu.org/software/ddd/
cost: free
Documentation: lots for ddd. none for php-dbg.
Did it work?: no
There's a lovely screen shot on the dbg website of dbg working within
ddd. That was as close as I got to seeing these two play together. DDD
just did not know dbg was out there and I dont see any docs on how to
hook them up. The good news is that both were available as RPMs so it
didn't take long to find out this wouldn't work.

PHPmole:
relevant URLs: http://www.akbkhome.com/
cost:free
Documentation: sparse. incoherent.
Did it work?: Hell no.
This was the one I wasted the most hours on. It requires scads of php
plugins and libraries. Each of which has their own prerequisites and
idiosyncracies. Even after successfully installing them, phpmole still
insisted that some weren't there. After hours of finagling I finally
got it running enough that I could edit a file but when I hit "Run" it
swiftly crashed every damn time. Argh!!

PHPed:
relevant URLs: http://www.phped.com
cost: $300 after 30 day trial period
Documentation: lots.
Did it work?: mostly
This is a commercial product by NuSphere. No trouble installing it. It
has a decent looking GUI. While not exactly intuitively obvious it
didn't take long to figure out how to edit a file, run, and debug it.
For some reason it started Mozilla and it appears to spawn Apache to
actually run the code rather than feeding it to an internal engine.
This is an annoying overkill and inexcusable for a $300 package. It
also means it has one fatal flaw: you cant stop an infinte loop. If
you're sloppy (and I am, or I wouldn't need an IDE) and create an
infinite loop (which I managed to do in just a blurb of test code) and
hit RUN you're stuck watching the scroll bar in the output window
shrink and shrink and shrink as you're code runs off into never-never
land. The STOP button wont stop it. The PAUSE button wont pause it.
You're only option is to quit PHPed, fire up an xterm, run top, seek
out the offending php job (it's not hard to find, it's consuming 96%
of the cpu), and kill it. This is not a good feature. Once the 30 day
trial expires it supposedly stops working altogther. So PHPed is not a
viable option for an impoverished grad student looking to get off
cheap (as a rule I wont buy any software that costs more than my car.)

Zend Studio:
relevant URLs: http://www.zend.com
cost: free 21 day evaluation, $200 or crippleware after that
documentation: lots.
Did it work?: yes
Another commercial product. No trouble installing. Nice looking GUI
though it manages to look cluttered and a little emaciated at the
same time. Again, though not exactly intuitively obvious to the
uninitiated, it was not too hard to get started, edit a file, run, and
debug it. For 21 days you get to play with the full version. After
that you can pony up $200 or live with the 'personal version' that
disables a few frivolous functions nobody uses anyway like Print. Oh
well, I can always cut and paste into kwrite. Another feature that
stops working after 21 days is the profiler. But since I dont know
what that is and the odds are I wont get that far in 3 weeks I suppose
I'll never miss it. As long as I can set breakpoints, step through the
code, and watch variables I'll be happy.

Sorry to say it, but the open source movement that gave me this great
OS has not produced a decent PHP IDE yet. It's worth keeping an eye on
the eclipse php plugin and the ddd DBG plugin. But for now, if you're
looking to get off cheap, the crippled Zend studio is the best option
I've found.
Apchar.

On 6 Nov 2003 00:33:32 -0800, apchar@yahoo.com (apchar) wrote:

>All I wanted was an editor with highlighting that
>would let me set breakpoints, step through my code, and watch
>variables change ("... and memories of Turbo-Basic danced in their
>heads.")

This is going to sound a little strange, but why not just stick a
constant into your script that causes output of technical data along
with the html ?

Vim and/or Textpad are all I've ever needed to work on PHP scripts...

kafooey wrote:

> On 6 Nov 2003 00:33:32 -0800, apchar@yahoo.com (apchar) wrote:
>
>>All I wanted was an editor with highlighting that
>>would let me set breakpoints, step through my code, and watch
>>variables change ("... and memories of Turbo-Basic danced in their
>>heads.")
>
> This is going to sound a little strange, but why not just stick a
> constant into your script that causes output of technical data along
> with the html ?
>
> Vim and/or Textpad are all I've ever needed to work on PHP scripts...

Let's just hope "Karim" doesn't lurk in this group...
http://tinyurl.com/twpg

;)

--
Justin Koivisto - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

kafooey (55.829% quality rating):
>
> This is going to sound a little strange, but why not just stick a
> constant into your script that causes output of technical data along
> with the html ?

Or trace it on paper if you really have to.

/joe
--
In Denny's, a program from the 118 will go to SONIC. In LiveJournal, a
network cable from the ULC will go to some bastard from IS.

<snip>

Would love to hear your comments on http://www.phpedit.net/

On Thu, 06 Nov 2003 17:20:27 +0000, André Næss
<andrena.spamreallysucks@ifi.uio.no> wrote:

>Because that means you have to actually *write* all the code to output
>technical data. The extra lines make the code less readable and less
>maintainable. They lie dormant 99% of the time. They simply don't belong
>there.

....but unless you are giving the source code away would you not remove
all the debug code from the release version anyway? (and obfuscate
it).

kafooey:

> On 6 Nov 2003 00:33:32 -0800, apchar@yahoo.com (apchar) wrote:
>
>>All I wanted was an editor with highlighting that
>>would let me set breakpoints, step through my code, and watch
>>variables change ("... and memories of Turbo-Basic danced in their
>>heads.")
>
> This is going to sound a little strange, but why not just stick a
> constant into your script that causes output of technical data along
> with the html ?

Because that means you have to actually *write* all the code to output
technical data. The extra lines make the code less readable and less
maintainable. They lie dormant 99% of the time. They simply don't belong
there.

Profilers and debuggers are extremely valuable tools.

And Emacs is of course The One True Path :)

André Næss

André Næss wrote:

> kafooey:
>
>>On 6 Nov 2003 00:33:32 -0800, apchar@yahoo.com (apchar) wrote:
>>
>>>All I wanted was an editor with highlighting that
>>>would let me set breakpoints, step through my code, and watch
>>>variables change ("... and memories of Turbo-Basic danced in their
>>>heads.")
>>
>>This is going to sound a little strange, but why not just stick a
>>constant into your script that causes output of technical data along
>>with the html ?
>
> Because that means you have to actually *write* all the code to output
> technical data. The extra lines make the code less readable and less
> maintainable. They lie dormant 99% of the time. They simply don't belong
> there.

Extra lines don't necessarily make the code less readable... It depends
on how you go about it and if you have comments stating what they are for.

For instance, if you have custom catch/throw methods, why remove them?
You'll just have to add them back in later if you need to debug again.
For that matter, any dubugging code can be handled correctly... If done
correctly, you can have readable code that makes sense and still have
the debugging code there when you need it.

Something similar (over simplified for example) would be:

at top of script (or in common included file):
define('DEBUG',TRUE); (or define('DEBUG',FALSE); when not debugging)

Then you'd have (using MetaBase for instance):
<?php
$result=$metabase->Query($query);
if(!$result){
// something went wrong
if($DEBUG){
// if in debug mode, display information
echo $metabase->Error();
}else{
// handle the failure for production server
}
}else{
// query success, continue processing
}
?>

What's so unreadable about that? Make perfect sense to me, and it's
still clean.

> Profilers and debuggers are extremely valuable tools.

Only if you know how to use them correctly. Putting something like that
into just anybody's hands could prove problematic...

--
Justin Koivisto - spam@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

That sure won't work under Linux.

Iky wrote:
> <snip>
>
> Would love to hear your comments on http://www.phpedit.net/
>

kafooey:

> On Thu, 06 Nov 2003 17:20:27 +0000, André Næss
> <andrena.spamreallysucks@ifi.uio.no> wrote:
>
>>Because that means you have to actually *write* all the code to output
>>technical data. The extra lines make the code less readable and less
>>maintainable. They lie dormant 99% of the time. They simply don't belong
>>there.
>
> ...but unless you are giving the source code away would you not remove
> all the debug code from the release version anyway? (and obfuscate
> it).

Even more work. So it's another argument against inserting debug output.

André Næss