If you have a more recent version of Eclipse you’ll want to download the plug-in directly from Adobe rather than using the CD. At the time of this post that will get you version 3.0.2, which is compatible with Eclipse 3.4 (Ganymede) but still not compatible with Eclipse 3.5 (Galileo). If you want to use the plug-in you’ll have to downgrade to 3.4.

Hope this information can help somebody. It would have saved me a few hours of frustration the other day.

Also: Eclipse 3.4 lists WST 3.1.0 as an available update. Don’t do it. It is incompatible with 3.4 and will make it so you can’t even open an editor window. Stick with 3.0.x. Why they tell you to install incompatible updates with all their dependency checking, I’ll never know.

Try sorting, reordering columns, and resizing columns. They all work.

Right-click the grid to view the source. When I get some free time I’ll turn it into a reusable component that you can apply to any grid. Feel free to use at your own risk .

Enjoy,
Alvaro

I wanted a way to train SA’s bayesian filter, without having to do a lot of work on my part.  SA provides a utility, called sa-learn, that when fed with spam or ham, will train its bayesian filter.  Python includes libraries for dealing with various mailbox formats, including Maildir, which is used by my mail server.  I could see all the pieces, I just had to work out the details.  So here’s what I did:

I created a folder named “Learn as Spam”, and one named “Learn as Ham”.  I already had a folder named “Trash”, and another named “Junk”.  The “Junk” folder is where SA currently put mail it thinks is spam.

Next I wrote a script, that runs SA’s sa-learn program to scan the messages in various Maildir folders on my server.  After sa-learn does its thing, the script moves messages from the Learn as Ham folder into the Trash folder.  The messages in the Learn as Spam folder get moved into the Junk folder.

Now in order to train SA on a spam email, I just move it to the Learn as Spam folder, and you can guess what I do with ham.  But to make things one step easier, I setup Apple Mail to use the Learn as Ham folder as the Trash folder.  This means that when I delete an email, it’s automatically moved into the Learn As Ham folder. Nice and easy.

As an additional bonus, the messages SA is trained on, don’t get deleted right away.  They go into either my Junk or Trash folders, which each retain messages for 30 days.  So if I accidentally file an email in the wrong place, I have 30 days to detect and fix the error.  I simply drag the message from where ever it is, into the appropriate Learn folder, and SA re-learns the email.

Sound useful?  Here’s the script.

These comments were made three days ago. I think this is about the five thousandth time I have read these exact same sentiments. I’m not saying they are not true, but they are no longer original thoughts. Please stop attaching them to every single PHP-related post on the internet. It’s just something that everyone has heard and that is generally accepted common knowledge about PHP, so let’s just make it official:

First Theorem of PHP: PHP has a low barrier to entry, therefore it tends to attract a lot of inexperienced programmers.

Corollary to First Theorem of PHP: There is a lot of bad code written in PHP.

“But, Jennifer,” you are surely saying, “doesn’t this mean that you are incredibly lonely and unsure of yourself? Doesn’t this mean that you need to exercise your femininity by joining special support groups, posting compromising photos of yourself on your blog, and proudly flaunting how you are different and special to anyone who will listen?”

No. No it doesn’t.

I don’t mean to be rude or unappreciative of the efforts people have made to create female developer communities, but I don’t get it. Being a black sheep makes me work harder to NOT stand out. The thought of being treated differently, whether positively or negatively, just because I happen to be female is awful. I want to be judged on the merit of my work, and parading around in purple shirts and “raising awareness” about the plight of the lone female in the IT department just cheapens the real efforts we are making in our field. It’s annoying enough to get comments all the time like “Wow! A girl developer!” or “Wow, my girlfriend can’t even work the microwave!” Then I go to these sites and read “Wow, a group of females that actually gets excited about this stuff!” I really hate that shocked tone, and yet we use it on ourselves.

Also, I don’t understand the concept of feeling excluded and therefore creating a club to exclude others. It’s all a little too “No Boys Allowed” for me. I understand the desire to connect with other female devs, but do we actually need sororities? Also, what happens when you start a forum for programming help and then exclude 90% of the people qualified to answer your questions?

I want to be described as a solid developer, a great developer, a knowledgeable developer… not a “girl developer.”

I ended up reinstalling the Apache 2 version of the PHP 5 package, but found the assertion in the instructions that “PHP should now be up and running” to be incorrect. For some reason the installer script did not add the necessary line to the httpd.conf file, located at /etc/apache2/httpd.conf for me:
LoadModule php5_module /usr/local/php5/libphp5.so
I added this, restarted the server via the Sharing control panel, and… nothing. Now Apache wasn’t even running, despite the green light in the control panel. Running “apachectl configtest” revealed the following error:
httpd: Syntax error on line 116 of /private/etc/apache2/httpd.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found.  Did find:\n\t/usr/local/php5/libphp5.so: no matching architecture in universal wrapper
Ah. OK. This was sounding familiar, and I followed the instructions in this forum post, Problem 2 and Problem 3, to get Apache to play nice with the Entropy package. After this I added the following lines to /usr/local/php5/lib/php.ini to point it to my XDebug .so, installed using “sudo pecl install xdebug”:
[xdebug]
zend_extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so
… and all was well. Or was it?

It seems that the problem here is that as part of Leopard, Apple switched over to using a 64-bit version of Apache 2. This was fine for them because their crippled bundled PHP 5 extension was updated to match. However, I was unaware of the issue and since I don’t use my desktop server much, it took me a long time to notice… during which time my PHP code was open to the world.

I want someone to blame here but the only person to blame is really myself… using non-standard packages, and not at least checking my external interfaces after a fairly major upgrade. Let this be a lesson: You never know when a seemingly simple upgrade is going to cause a huge security hole, even on your little home machine. Always take the responsibility of hosting seriously.

P.S. Marc Liyanage, where did you go? If you’re not going to update the packages anymore, please let someone take over for you… there are a lot of books and tutorials pointing to your packages…

This transparency is a huge advantage that Data Mapper pattern has over Active Record implementations.

Although the PHP solutions are all MUCH better than not using an ORM at all, they all seem to have serious issues:

• All of them litter your entities (models) with properties and methods used for mapping and saving the entity to the database. This uses up memory and makes the output of “print_r” or “var_dump” full of stuff you don’t expect there.
• EZPDO (and probably others) doesn’t give you back a a real instance of your entity, instead it gives you some object that maps to it, breaking code that uses “instanceof” or type hints.
• Propel, Doctrine, and all Active Record implementations force your entities to extend from one of their classes, which prevents them from extending anything else. (I know there’s some workarounds for this).
• Propel requires complex criteria objects just to create a simple where clause such as ‘WHERE StatusID = 1 OR StatusID = 2′ (you could do this with Criteria::IN, I just couldn’t come up with a better example).
• They are all very big, which might be ok for a platform that holds its objects in memory across requests, but not PHP which re-instantiates them every time.
• Doctrine, EZPDO, and others encourage the use of their own form of SQL. While it may be handy in certain situations, I’ve only had to change database vendors in the middle of a project once in my career and the queries that are difficult to port are never the ones that an ORM would generate for you. They are usually the custom built ones that take advantage of vendor-specific features.

None of these are necessarily deal breakers, but I thought a new PHP ORM could do a much better job.

A few of months ago I started working on Outlet and a few days ago I released version 0.3. I believe it takes care of all of these issues very cleanly. It is unobtrusive and keeps your entities very clean. It provides just enough abstraction while staying very small, just a handful of classes. You can use regular SQL (call vendor-specific functions if needed) while still abstracting out the actual names of the tables and columns. It also feels very much like PHP which was an important objective.

Please check it out and let me know what you think. Keep in mind that it’s a work in progress and there are a lot of features I still would like to implement. That said, I started using it in some of my projects and I’m VERY pleased with the results.

Website: http://www.outlet-orm.org

It is open source (New BSD License) and I am very interested on user feedback. I set up the following google group (forum/mailing list) for anyone interested in submitting questions, bugs, feature requests, etc:
http://groups.google.com/group/outlet-orm

Alvaro