boogdesign blog

Link: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1258

I'm now moderating a forum on IBM developerWorks:

A forum, moderated by Rob Crowther, to discuss building web pages and sites that are a part of the Semantic Web. We'll cover the main front-end technologies such as RDF, RDFa, Microformats, GRDDL and OWL. This is a community for us all to learn together about how to build the next generation of the Web.

If you have any questions about Semantic Web technologies, or just want to share your ideas, please come along and make a post.

Link: http://www.ysearchblog.com/archives/000527.html

This might be big news for the Semantic Web, or it might not mean much at all. In one way, this doesn't change very much - Yahoo! is very much niche as far as search engines are concerned (in the UK at least), MSN/Live has overtaken them in terms of referrals on the websites I work with (probably because of all the new installs of Windows which have that set as the default search provider, rather than because their search is better), but both are dwarfed by Google. In another way, it might be enough benefit to make people think it's worthwhile to start adding more semantic markup, which in turn might lead into a virtuous circle which quickly ramps up the amount of semantic web content available to a critical mass.

A mere five months after the release of SuSE 10.3 I finally got round to upgrading my aging laptop. Of course, I was still on 10.1, so I'd already waited ten months before that

I downloaded the main ISO and the extras one, and booted off the CD. Encountered a slight problem getting it to boot initially, but when I clicked for 'view details' in the boot process I saw a helpful message about adding brokenmodules to the boot options. I also had to disable acpi, so I ended up with these options:

acpi=off brokenmodules=pata_ali

The next issue was I had a load of extra repositories enabled on 10.1, and it turned out the Guru repo is now part of Packman so you have to disable it before starting the upgrade, otherwise the upgrade hangs.

After that it was more time consuming than complicated, I had a load of package conflicts to resolve, and for a time it seemed like I was going round in circles with that. Then I just had to wait overnight while it did the actual upgrade, and now I have it all installed and working.

The default KDE theme is a bit different, lots of faux transparency, and there's a new, more compact, application menu which is quite nice, but otherwise not massively different from the end user point of view. With some updated underlying packages I'm hoping I'll now have a better chance of installing more recent software.

Link: http://www.ibm.com/developerworks/xml/library/x-plansemantic/

I've been published by someone other than myself! Read my introductory article on applying Semantic Web technologies to your website on IBM's Developerworks site. Although it's mostly my own words, I had a lot of help from the guys at Backstop Media, who were great. This was an interesting experience for me, from frantic writing into the early hours of the morning to being interviewed through my mobile while standing in a fire escape stairwell. I was kind of nervous about the whole thing, but got great support all the way through.

If anyone's followed the link from the article back to here, then welcome! Please feel free to let me know what you think in the comments to this post (they're moderated, but I check a couple of times a day). In the meantime the potential influx of visitors is motivation for me to complete all those half finished posts I've got lying around from the last five or six months and try and look like less of a slacker

Link: http://googlemobile.blogspot.com/2008/03/shifting-google-gears-to-mobile.html

Web as ubiquitous computing platform got a boost today as Google announced a version of Gears for Windows Mobile 5 and 6 devices. Google Gears is a browser extension which lets web applications work offline, which is a crucial requirement if you're planning on doing any serious application for a mobile device where the connection is likely to drop in and out relatively often (compared to your desktop PC). It's a shame that they've not started with Symbian, the most widely deployed smartphone OS outside of the US, but hopefully they'll get to it shortly.

And while on the subject of Symbian based OSes, Microsoft also made an announcement in the mobile device space today - they have agreed with Nokia to write a version of Silverlight for Series 60 (which is Symbian based) phones. I admit I hadn't really taken Microsoft's 'cross platform' claims for Silverlight that seriously up until now, because they weren't even as 'cross platform' as Flash, which is hardly the gold standard, but a few more announcements along these lines and they might convince me.

For many years now, I've used various versions of Jack's FormMail.php to handle simple form submissions on various websites, mostly 'contact us' forms. The script has gotten a little more sophisticated with time, but it's still one of the simpler ways of making a website 'interactive.'

The website at work uses it to send the marketing department emails when someone fills in the contact us form. The form is somewhat sophisticated, in that it presents different information depending on a few parameters in the URL, and passes formmail.php a different subject for the email depending on what configuration it's in. It also passes a redirect URL in a hidden field, so the user is redirected to a 'thanks for contacting us' page after submitting the form. Google Analytics is set up so that any hits on the 'thanks' page after viewing the contact page counts as a Goal. And this is where I spotted the problem - as I checked through the Analytics stats I noticed we hadn't achieved any goals since the middle of last week, although a day or two here and there without any is fairly common five on the trot is pretty rare.

My first step was to go to the contact form and try submitting it, the email duly arrived in the correct mailbox but the script didn't redirect to the thanks page. So first mystery solved, no hits on the thanks page means no goals on Analytics, but the marketing department hadn't noticed because they were still getting emails. I messed around with some of the different configurations of the contact page but none of them redirected as intended. Then I realised that all the emails had the same subject, and that was the default one given by formmail.php when it doesn't get passed a subject, though the values in the form fields were appearing in the email correctly, so it wasn't like the information wasn't getting passed though.

I checked the web host's page and discovered that they had recently updated the PHP config on the server, this in order to support PHP v5. There was a new option in CPanel to select the default version of PHP, so I went and set it to v4 in case formmail was incompatible with the newer release. It didn't make any difference though, so I started looking at formmail.php itself in detail.

The first thing I noticed was that the redirect functionality required register_globals to be enabled. Although my PHP configuration page claimed that register_globals was enabled, the behaviour of the script indicated that it wasn't. Unsurprisingly, the subject field also expected register_globals to be enabled, as did several other fields which I wasn't using, but the code which builds the email uses $HTTP_POST_VARS so works fine without.

If you've managed to read this far without falling asleep and you know what register_globals is, then you now have enough information to fix the problem yourself and there's no need to torture yourself any further. If you currently have no idea what I'm on about, I'm now going to try and explain and then show you how to edit your script to fix the problem. register_globals is a configuration setting for the PHP interpreter, if it's set to on then PHP will helpfully make any parameters passed into the script global variables. Parameters are the bits in the URL after the question mark, or fields in a form. This can be quite handy when you're slapping together a quick script, but is also very dangerous because, if you're not careful, you can create easy opportunities for hackers to do nasty things. For this reason, register_globals = on has long been discouraged in the PHP community, unfortunately many useful scripts were written in the days before anyone realised it was an issue, so web hosts usually provide a way turn it back on even if it's not enabled by default.

However, today we're going to make formmail.php work properly with register_globals = off. You're going to need to open the formmail.php script in a text editor - Notepad will do fine. First we shall fix the redirect issue, find the following lines near the end of the file:

if ($redirect) {
   header("Location: $redirect");
   exit; 

We're going to replace $redirect, which is trying to access the global variable, with $_POST['redirect'], like so:

if (isset($_POST['redirect'])) {
   header("Location: ". $_POST['redirect']);
   exit;

The same trick works with the subject and email address, scroll up a few lines and find this:

mail_it(stripslashes($content), ($subject)?stripslashes($subject):"Form Submission", $email, $recipient); 

Replace it with:

mail_it(stripslashes($content), isset($_POST['subject'])?stripslashes($_POST['subject']):"Form Submission", $_POST['email'], $recipient);

Now upload your new version to the server and you should find things start working as before. As you can see the general rule is to replace $variable with $_POST['variable'], notice that I didn't change $recipient because I always hard code that value at the top of the script as a security precaution.

We had a potential client which wanted to use our web application on their Blackberry Pearl devices. I figured "How hard can it be?", downloaded an emulator and got cracking I wanted to make the standard pages support the Pearl, I didn't want to write a whole new web app, without changing how they worked on desktop browser to avoid confusing existing customers.

The tips below are things I specifically ran into on the Pearl, I imagine they'll apply pretty well to any low end mobile browsing device.

Tables make layout inflexible - the Blackberry has a fairly narrow screen when compared to a desktop. If your form laid out is in a table which is several hundred pixels wide the chances are it's not going to fit in the width. Since your page is most likely already too long for the display this is going to leave users having to scroll in two axes to complete the form. To avoid this I changed all the forms I expected to get used on the Pearl into a tableless layout which then used CSS to achieve the same display on the desktop, and then add a mobile stylesheet to override this:

<link rel="stylesheet" href="style/handheld.css" media="handheld" type="text/css">

This meant they lay out in a grid on a desktop browser but in a linear column on mobile devices

No javascript by default - the web app I was working with has been in production for more than five years, so it has it's share of hairy code particularly in the javascript department - a mixture of inline and external. One of the main issues for me was that so much of the supporting functionality depended on JS - for instance the search form could be filled out and submitted, but the functionality for scrolling through the results depended on onclick events on buttons. I re-wrote the forward and back buttons to be wrapped in little forms of their own which submitted to the correct URLs to solve that fairly easily (and that worked just as well for full desktop browsers too).

The more difficult situation was the input form, which, although it allows free text input, also allows you to select from a list of available options. Unfortunately the way this has always worked is for users to click on a button which launches a pop-up window, then double click on the item they want out of the resulting select list. The value is then inserted into the main form and the window closed, and the whole process is driven by javascript.

So, obviously it's not going to work at all without any javascript. I should point out this represents a bad design decision, I should have started with a form which worked without javascript and layered the enhanced behaviours on top (a technique known as progressive enhancement, but way back when the decisions were made I didn't know any better and neither did anyone I worked with. So I was re-writing the page in my ASP era web app, but I wanted to keep visually identical (close enough, at least) to the previous version. Here's an example of what the form components looked like before I started (names have been changed to protect the innocent):

<tr>
<td>
  <input class="standardWidth" value="Service Group" onclick="openPopup('Default.asp?WCI=listItems','PopUp','300','680');" type="button">
</td>
<td>
  <input autocomplete="off" name="txtITEM" id="txtITEM" size="25" maxlength="20" title="Click button to display list" value="" type="text">
<div style="display: none;" class="auto_complete" id="txtITEM_complete">
</div>
<script type="text/javascript">
new Ajax.Autocompleter('txtITEM', 'txtITEM_complete', 'Default.asp?WCI=listItemUL', {minChars: 2});
</script>
</td>
</tr>

A quick note here so you don't get lost - I'm using scriptaculous for the auto complete, openPopup is a fairly standard popup function, all the server side functionality is encapsulated in a WebClass, basically a VB6 DLL embedded in an ASP page, so different pages are called up by varying the WCI= parameter.

After I'd switched to a tableless layout (see above), my first step was to comment out all the javascript, this broke everything Next, I changed the input element to be a submit. Every button on the form would submit it and I planned to then detect which button had been clicked on the server side. This is relatively straightforward, just give all your submit buttons a common name (but a unique id so you can reference them individually in script):

<div>
    <span class="colLeft">
        <input type="submit" name="butLogForm" id="subITEM" class="standardWidth" value="ITEM">
    </span>
    <span class="colRight">
        <input type="text" name="txtITEM" id="txtITEM" size="25" maxlength="25" value="" title="Click button to display list">
    </span>
</div>

Then, on the form target page you check the value of butLogForm, so in VB6/ASP it's Request( "butLogForm" ), and its value will be the whatever you assigned to the button which was clicked (ITEM in the above example). So if a button other than the 'main' submit button has been pressed it's easy to detect this and redirect to the appropriate selection page for the field (which would be the same page as was originally appeared in the popup window summoned by clicking the button). I then added some plumbing to direct the popup page to either submit the value as a form or populate with javascript into opener depending on how it was called and to capture all the values behind the scenes once the user had selected them.

So now the form worked fine with javascript disabled, the only task left was to make it work as it did before in a desktop browser, popup windows and auto-completes, when javascript was enabled. This was slightly complicated by the need for the javascript to know the URLs for all the pages, and these could be changed at runtime, so I decided to pass them all in as parameters to the onload function (there is a URLFor) utility function available within the webclass which calculates them). To reduce the number of URLs to be passed in I used a naming convention so that the URL for the auto-complete function could be easily generated from the popup URL by appending 'UL' to it:

if ($('subITEM')) {
    $('subITEM').onclick = function () {openPopup(urlITEM + '&IsForPage=Log','PopUp',width,height); return false;};
    if (!$('txtITEM').readOnly) {
        var elTxtITEM = $('txtITEM');
        acDiv = document.createElement('div');
        acDiv.className = "auto_complete";
        acDiv.id = "txtITEM_complete";
        elTxtITEM.parentNode.appendChild(acDiv);
        new Ajax.Autocompleter('txtITEM', 'txtITEM_complete', urlITEM + 'UL', {minChars: 2});
    }
}

The code is fairly simple. First I check to see if the relevant submit button actually exists (there are configuration settings in the app to turn each field on and off) and, if it does, adds the old popup code to the button. Next I check to see if the text field is editable (another configurable option) and add both the div required by the Ajax.Autocompleter and then initialise the control itself.

The <button> element is useless - well it might not be completely useless, I didn't try too hard, but I decided I was only using it in the first place to show off my l33t HTML skills so I just switched them back to regular input elements.

No CSS by default - the browser on the Blackberry Pearl will not use CSS by default, though you can change the configuration to enable it and it will then respect the mobile stylesheet. The main problem this posed for me was that, in a lot of places, I was relying on padding and borders to provide spacing between text elements, eg:

<div><span><strong>Status:</strong></span><span>Active</span></div>

So when CSS is turned off you end up with tall the text running together with no spaces in between, making it hard to read. Since in this situation it's impossible to control the presentation with CSS I resorted to using markup for it and added &nbsp; glyphs inside the spans in every place where the text needed a space.

Turning on javascript leads to memory errors (slowly) - just like CSS, the browser on the Blackberry Pearl will not use javascript by default. This leads to the issues I already covered above, but a more amusing issue occurs if the user happens to enable javascript. The Pearl is a low memory device, even compared to other smart phones, and if your web app has several hundred kilobytes of javascript for it to download it will use up all of that memory in a vain attempt to parse the file. Since all the javascript gets downloaded in a standard header this led to a long wait and then an error message when you even tried to access the login page on my app. I made an extremely cut down javascript file, basically the standard field validation and date formatting functions, the openPopup function and some empty function stubs for all the onload functions (to avoid error messages). Since I didn't have the time or resources to implement WURFL or DeviceAtlas and this is only ever likely to be used in controlled corporate environments, I made a user configuration setting in order to send the cut down version to the Blackberry instead of the regular JS .

Only onchange on inputs, no onblur or onfocus - the final thing that caught me out was to do with my validation and formatting helpers on text inputs, these were all hanging off onblur and were not getting fired on the Pearl. The quick solution was to change everything to onchange instead, though the reason I'd used onblur in the first place was because I'd experienced some unreliability in the desktop browsers so this was not ideal. Unfortunately I had to wrap up this project before I had chance to get into it in more detail.

I started a new project at work today, adding some ajaxy interactivity to a slightly long in the tooth web application. In a previous iteration I'd plugged prototype.js 1.5.1 into this app, now I wanted snazzy effects and autocomplete fields. Figuring it was a good time to move up to the latest version of scriptaculous, I downloaded the recently released 1.8.0 version (which includes prototype 1.6.0).

I had to do some hacking around in my 'legacy' javascript to get things working in Firefox (that's how long in the tooth this application is), and then I added my Ajax.Autocompleters, got my afterUpdateElement callbacks working and was starting to feel generally quite chuffed with myself at how well it was all going. Then I thought I'd give it a quick check in IE...

In IE7 the up and down arrows didn't scroll up and down the autocomplete list, which made the whole thing kind of useless. A quick check in IE6 confirmed the same issue there, so I immediately resorted to Google. Unfortunately the answer wasn't immediately apparent in the search results and it was only when I started searching the Ruby on Rails Trac directly I finally homed in on the answer. Hoping that I can help future searchers home in on this more quickly, here's the defect: "some keypress events don't work in IE6/7"; and here's the fix.

Link: http://gmailblog.blogspot.com/2007/10/sync-your-inbox-across-devices-with.html

Following up on the increased storage (now over 4Gb) and the improved support for mobile phones, this week Google rolled out IMAP support for Gmail. I access all my other mail accounts through IMAP, so I don't need to be convinced of the benefits - mostly (for me) a consistent view of your entire inbox (including sent items) across all the mail clients on all the different PCs I use to read my email (currently six, and now my mobile phone). If you're not so sure, try reading "Why IMAP is better than POP" or "POP vs IMAP for Inboxes."