2005 December

Several New Pearified Packages

I rolled out several new Pearified.com packages last night and this morning. A brief summary of these updates:

• Frontend packages switched to Role_Web usage. Packages that have a frontend component now require the Role_Web custom role. This allows you to set a web_dir value via PEAR config. See a description of this plan here.
• Prototype, script.aculo.us and Behaviour packages updated. script.aculo.us and Behavior actually have new versions, while the Prototype package was just re-built to use Role_Web.
• New Editors category added. I've packaged TinyMCE 2.0.1 as Editors_TinyMCE to kick off this new category.
• Icons, Icons, Icons. I've added a new package called Icons_Silk which bundles up Mark James' great Silk icons. Also, I re-released a bunch of packages containing variants of the Tango Project icons. You can now install sizes ranging from 12x12 to 128x128, in four pixel increments. Those packages are further split out into alpha-transparent PNGs, and for the Internet Explorer-using crowd, versions with white, black and light gray solid backgrounds.
• Tooltip! Finally, after a good IM chat with Davey Shafik last night, we agreed that his new Tooltip package will have its PEAR channel home on Pearified. Check that package out -- it's very well done.

That's all for now! Enjoy these packages, and please let me know if you find them useful.

A Call for Feedback

After reviewing my Zend Download Server logs today for Pearified.com, I was surprised to see that there have been several hundred downloads of the Pearified JavaScript and other "front end" packages.

While the numbers are a little strange when you take dependencies into consideration, here's what I've served so far:

JavaScript_Prototype        354

JavaScript_Scriptaculous    431

JavaScript_Behaviour        164

phpMyAdmin                  131

Role_Web                    169

Assuming that some people are downloading all of the packages, and some are downloading them for multiple sites, etc, I figure there are at least 80-100 people who are following (and maybe even using) these packages.

So, silent users, what do you think of this idea?

I'm starting to believe that PEAR-installed "front end" packages should go into a /webpear directory in a site's DocumentRoot, with channel packages going in subdirectories of that /webpear directory.

Currently, the Role_Web package allows the DocumentRoot to be set anywhere. That will not change; what I'm thinking of is a "socially-enforced" guideline rather than a programatically-enforced one.

There may be good reasons at times to have front end packages that are installed outside of the /webpear directory, but in general I'm suggesting that packages which use the Role_Web role set their 'baseinstalldir' value to /webpear/[channel]/[whatever is appropriate].

For example: One of today's Icons_Tango files would then become available at:

http://www.example.com/webpear/Pearified/Icons/Tango/48x48/categories/applications-games.png

The biggest benefit is that applications/packages that want to introduce dependencies on these files would know exactly where to find them, and how to call them without relying on any fancy footwork or additional configuration.

What do you think, silent ones? This would eliminate the need to symlink, import files via loaders, or set up Apache aliases for these files. The downside is that it would create some long paths within the /webpear directory ... but, if you don't like that, you could always do a symlink or alias anyway, just like you have to now.

Let There Be Good Looking Applications

Let There Be Good Looking ApplicationsIn another small step toward putting a slick application together completely out PEAR-installable components, I put up a PEAR package of the Tango Desktop Project icons today.

I'm looking forward to putting these to use in a few things, and I'll be interested to hear if anyone else finds PEAR-installable icons handy as well.

Grab a copy of the icons:

$ pear channel-discover pearified.com

$ pear install pearified/Icons_Tango

That will create a directory in /[path to pear]/Pearified/Icons/Tango. You can then access the icons a number of ways in your applications:

• Create a loader.php script that outputs a PNG header and then does a readfile() on the image you want.
• Create a symbolic link in your web document root to the Pearified/Icons/Tango directory, then use regular HTML img tags to use the icons.
• Or, if you're using Apache and control your config files, use an Alias directive in your VirtualHost container (sorry, .htaccess files don't allow the Alias directive) to point to the location of the Pearified/Icons/Tango directory.

Why not use the Role_Web package? I thought about packaging them that way, and may switch to that at some point in the future. If you'd prefer the Role_Web method of packging these icons, please speak up in the comments.

Coal and Switches in Zend’s Stocking This Year

So here it is -- December. We've got a shiny new PHP 5.1.1, which as been anticipated for weeks, at least. (I'd been expecting its release any day for a good 2-3 weeks before it finally shipped.) We've also got a zippy new Firefox 1.5 release, another project whose release was fairly well telegraphed and expected for the last month.

And then we've got Zend Studio, a cornerstone of "The PHP Company". After upgrading to PHP 5.1.1 and Firefox 1.5 this week, I was been shocked to discover that Zend Studio 5 and the Zend Studio Firefox Plug-In are both in a state of rectal-cranial inversion: neither Zend Studio 5 or the Firefox Plug-In are expected to support PHP 5.1.1 or Firefox 1.5 until late December/early January.

So, I won't be able to leverage the holiday lull to really hammer on projects in PHP 5.1.1 using the Zend tools I've come to rely on.

And get this: Zend's own product website for Zend Studio 5 claims support for All PHP Versions, and the Zend Studio Firefox Plug-In boldly claims to support Firefox 0.9 and above.

In reality, however, Zend Support's reaction to my support tickets raising these incompatibility issues was essentially: huh? Oh man, give us a month.

There's absolutely no excuse for this delay that can be considered acceptable for a company who claims to be "The PHP Company." Perhaps Santa will leave a clue under the tree for these guys.