Archive for July, 2009

I run into some issues trying to update subversion on our Linux 64-bit (CentOS) servers. In other words, RPM always complained on some missing dependencies from a old version and aborted the upgrade. The error lines were of the nature;

Transaction Check Error:
file /{filesuchandsuch} from install of subversion-1.5.6-0.1.el5.rf

I mean, I had the old subversion installed and wanted to update to the new one. Isn’t that what a update is all about?

After trying to remove, reinstall and reconfigure subversion I tried the update again, just to find out that it still did not work. So, i started to dig into CentOS and found that during the installation of subversion the RPM installed both the 64-bit and the 32-bit versions.

Since, I did not need the 32-bit version I removed it with;

rpm erase subversion.i386

Then tried updating subversion again with;

svn update subversion

BINGO! Apparently the 32-bit version interfered with the update. Removing it solved it.

Like many people, I totally dig WordPress as my preferred Blog software (despite it being written in PHP, but that is another story:-) ). The way I have WordPress installed my Linux host is that I get the latest stable releases with subversion directly from wordpress.org. So far, I have had never problems with it. But…

Since 2 days I could not access the WordPress Administration anymore. The page, after login, did load, but instead of the Dashboard I always saw a blank page with the browser still loading 11 of 12 elements. After some digging around and getting to know Firebug better each time, I saw that the “Thickbox.css” could not be loaded. Even calling it directly within the browser did not load the CSS. The same behavior was found on 3 other blogs I run.

After opening the thickbox.css file I saw that the writer had a couple of comment tags on top of some styles that looked like this:

/* —————————————————————————————————————-*/
/* ———->>> thickbox settings <<<—————————————————————————–*/
/* —————————————————————————————————————-*/

While nothing looked suspicious here, I nevertheless removed the comments (since I experienced some other weird stuff with comments in the past) and low and behold the WordPress Administration did load again without problems.

I’m not sure, where to put this in now, with a configuration of Apache or some malfunction of PHP, but I got a running WordPress again.

Hope this helps someone out there.

I have to say that I love the Adobe Spry Javascript framework. It is easy to use and simply just works. For most situations it comes with “widgets” for just about everything you need in your Ajax enabled web application.

One of my favorite widgets is the Text Validation one. With it you are able to validate just about everything the user enters and you will have full control of the input, even the pattern of the input.

But what about if you need a custom validation? According to the documentation you can use the “custom” parameter with a “pattern”. But if you use it, you actually apply a “pattern”, meaning applying a pattern of “pattern: “bbb” only allows the user to enter 3 alphabetical characters, but nothing more. Usually you want to have the user enter only alphabetical characters and not limiting the amount of chars.

In order to achieve this, you have the undocumented parameter called “characterMasking”! “characterMasking” combined with “usecharacterMasking: true” allows you to pass Regular Expressions to the text field you want to validate within the Spry syntax. Powerful stuff. It is beyond me, why Adobe has not updated their documentation on this. In any case, here is a example:

Say you want to allow only alphabetical character in lowercase and nothing else, you would use a syntax of;

var custom = new Spry.Widget.ValidationTextField(“myfield”,”custom”, {isRequired:true, hint:’some hint’, characterMasking: /[a-z]/, useCharacterMasking:true, validateOn:["blur", "change"]});

Would you like to only enable digits and spaces?

var sd = new Spry.Widget.ValidationTextField(“subdomain”,”custom”, {isRequired:true, hint:’Desired Subdomain’, characterMasking: /[ds]/, useCharacterMasking:true, validateOn:["blur", "change"]});

I guess you get the point. Combined with Regular Expression the Spry Text Validation Widget just entered into a new level of productivity.

Recently over at the website of our open source Digital Asset Management company Razuna Ltd., we published a desktop application that was build with Adobe AIR.

Now, while we could easily link to the AIR application, which all end with an extension of “.air”, within the web page it would prompt the user to install the application only under FireFox (both Windows and MacOS X), but users with Safari or Internet Explorer where prompted to download a “.zip” file.

In order to fix this, we had to change the mime type configuration of the web server itself. Now, we figured that there are different solution to this, depending on your web server;

For Apache

Adding the mime type for .air extensions with Apache requires you edit the file “/etc/mime.types” (on RedHat/CentOS) and adding the line:

application/vnd.adobe.air-application-installer-package+zip     .air

Make sure to reboot Apache to apply the changes.

For Tomcat

Adding mime types for your Tomcat installation requires you to edit the file “tomcat/conf/web.xml” and adding a new “mime-mapping” like;

<mime-mapping>
<extension>air</extension>
<mime-type>application/vnd.adobe.air-application-installer-package+zip</mime-type>
</mime-mapping>

Make sure to restart Tomcat to apply the change.

Using .htaccess

If you can’t access the server config files or you simply don’t want to, then the other option is to simply add the mime type to your .htaccess file.  Add the following line to it;

AddType application/vnd.adobe.air-application-installer-package+zip .air

Save it and you should be all set to make it possible to launch the Adobe AIR installer ones your .air file is downloaded.