Wonkenstein

drupal_add_js + hook_form_alter

Interesting little gotcha I came across when working with the drupal form_api

When you want to add a js or css to a page, drupal_add_js and drupal_add_css is usually the best way to do it rather than outputting <script> tags. I needed to do as we use some js to manipulate the node edit forms.

But I found that if you use these functions are used in hook_form_alter the js/css files don’t get included on the page when a form has been validated. It will only appear on the first load. I don’t know why for sure but think it’s related form building/caching.

Anyway, a bit googling revealed that a way to make sure that js/css files are included all the time is to use $form[‘#after_build’]. More info on this drupal thread http://drupal.org/node/322290 and here http://switchbackcms.com/blog/right-way-include-javascript-your-drupal-form

Web experience on ipad

I spent some time fixing some bugs on a web site I was building that needed to work on an iPad. It was my first time doing this and learnt some interesting things in the past few days.

Mouseover events
Mouseover/hover events won’t work properly or as expected on an ipad as that concept doesn’t exist on the device. When you tap on the screen on the appropriate element, it will become highlighted and trigger the onmouseover event if you have anything attached to it. But problems may occur when you have mouseover and click events mixed in.

For example, I had a table of data, each table row had a mouseover event to highlight the row that the mouse was over. In one of the cells of each table row, there was a link which I had attached a click event to.

On the ipad this functionality didn’t work as intended. When you clicked on a table row, the row highlighted. But when you clicked the link, it didn’t fire unless you tapped it twice which was unexpected. After a bit of poking, it turned out that the first click would activate the mouseover event, and the next click would activate the click event, rather than being triggered on the first click.

This was a bit annoying, but eventually managed to get around this by using browser sniffing and attaching what needed to happen on mouseover to the click event. Alternatively, these events could have been attached to the touch events that come with an iPad but click worked ok for the interaction we required. http://blog.0100.tv/2010/05/fixing-the-hover-event-on-the-ipadiphoneipod/ and http://www.danwellman.co.uk/fixing-jquery-click-events-for-the-ipad/ were helpful

Be careful with the user interactions when coding for an ipad/iphone. Some effects may need to be changed or attached to different events depending on the device, as it may make sense in one device but not in another.

Movie Playback
I had embeded a quicktime movie into a webpage and used custom elements and javascript to control the movie with play/pause, stop buttons and a video progress bar and volume control.
This all worked fine in the browser but didn’t work in the ipad.

After reading the apple docs it turns out using js to control quicktime movie playback won’t work on the ipad as native controls are used. http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html

I found some things worked such as the Play() function and changing the quicktime movie src/url but others such as Stop() wouldn’t. The safest way would be to hide the custom controls and let the user control the video using the native controls.

Audio
After embedding a quicktime movie for video playback, we used the quicktime player to play audio clips. This time we needed custom controls to control the playback, but as we couldn’t rely on this to work properly on the ipad, we ended up using the <audio> element, which we can manipulate using js.

After putting some conditionals to embed <audio> if it was an ipad, we had trouble getting pause() to stop the audio playback. We ended up with a hack to stop the playback by changing the audio player src attribute to ‘’ when we wanted to stop the audio playing which seemed to work.

Conclusion
These were some fiddly and interesting things to find out as it was my first time coding a web page to work in an iPad. There was a bit of hair pulling as some things weren’t obvious but are handy to know next time I have to get something to work on an iPad.