neverblog.net

The Blackberry: Sweet, juicy….Internet.

As PDAs and similar handheld devices continue to advance, it becomes more and more realistic to consider them in one’s site design, in order to reach the widest audience possible. Since I happen to have a Blackberry right now, I’ve been trying various sites in order to see what’s compatible and what fails miserably.

The usual suspects, such as Google and Gmail, performed flawlessly, as expected. The folks over at Google seem to a have a special little spot in their hearts for the mobile user, and their most popular offerings don’t disappoint in this regard.

Once I was sure that I’d maxed out my PDA’s capability to process client-side markup and scripting (you have to manually add JavaScript, Cascading Style Sheets (CSS), and XML support, otherwise you’re basically running Internet Explorer 4.0 on a teeny-tiny screen–a browsing experience that would make even the most desperate bsuite-hound run for the nearest Mennonite community), I headed over to this blog.

The front page loaded flawlessly, though it takes quite a while, and the Blackberry’s status bar indicates a laborious process of running scripts and proccessing CSS at what is, relatively, a snail’s pace. What surprised me the most was the appearance of a photo that went with one of the stories, nicely formatted and filling the screen. It’s easy to scroll through and read posts, click on related articles, and do pretty much anything else you’d want.

With the front page test complete, I tried logging in to the admin section. Navigating to /wp-admin yielded a standard userID/password dialog, and within 30 seconds, I was on the admin dashboard, free to click on any tab, change any options I wanted, and even post an article. As far as I can tell, WP works with the Blackberry, or rather, the Blackberry has no problems handling WordPress. It’s a far cry from the cell-phone internet I’m used to.

I plan to continue trying out sites to see where the Blackberry might get stuck. I’ll post if I find anything, and update this entry if I find any more significant sites or webapps that work.

UPDATE: I found a page with a really nice intro to CSS and web development on the Blackberry. Read about it here.

Filler Bunny: He takes up space

One of the best ways to add life to your blog posts is to include images with the text–your reader’s eye is naturally drawn to the large visual well before the text itself, and the addition of a picture can bring an element or realism to your post that would normally be missed. Many templates available on the web, however, fail to include a simple way to add captions to your images, limiting what you can do with them. For example, anyone posting a picture of, say, two dogs would be hard-pressed to indicate which was Rover and which Fido without the aid of a caption. The easiest solution is to place the image in a table with a caption, of course, but this adds several ungainly lines of code which you must type in by hand in order to add a single captioned image. Even copying and pasting, this method of posting captioned images is a serious pain at best.

Thanks to WordPress‘ QuickTags (the row of buttons directly above the post content itself on the Write page), however, it’s relatively simple to edit the ‘img’ button to create custom captioned images.

First, replace the function edInsertImage in /wp-includes/js/quicktags.js with the following javascript:

function edInsertImage(myField) {
var myValue = prompt(’Enter the URL of the image’, ‘http://’);
if (myValue) {
myValue = ‘<img src="’
+ myValue
+ ‘" alt="’ + prompt(’Enter a description of the image’, ”)
+ ‘" />’;
myValue = ‘<table class="alignright" width="’
+ prompt(’Enter the image width’, ‘250′)
+ ‘" border="’
+ prompt(’Border size:’, ‘0′)
+ ‘" cellspacing="0" cellpadding="0">’
+ ‘<caption align="bottom"><b>’
+ prompt(’Caption:’, ”)
+ ‘</b></caption><tr><td>’
+ myValue
+ ‘</tr></td></table>’;
edInsertContent(myField, myValue);
}
}

Now, at this point, once you’ve replaced your current quicktags.js, the ‘img’ button on the write page may or may not do what you want it to do. Chances are that you’ll have to add to your CSS as well before you can reap the benefits of the modified ‘img’ button, though. If so, place the following in your template’s CSS sheet:

table.alignright {
padding: 4px;
margin: 0 0 2px 7px;
display: inline;
}

table.alignleft {
padding: 4px;
margin: 0 7px 2px 0;
display: inline;
}

That should do it. Now whenever you go to add an image with the quicktags img button, it will prompt you for all the appropriate parameters to create a nicely captioned image like the one above. Should you wish, you can add other elements to the javascript, such as the ability to choose the color of the photo’s border.

UPDATE: Make sure you refresh the ‘Write Post’ page of WordPress after you modifiy your quicktags.js file. Otherwise, the cached (unmodified) version will continue to be used.

To create the previous post, I obviously needed to incorporate some Fireworks HTML into WordPress 2.0’s post editor in order to show the example. Having long since given up on the WYSIWYG editor that shipped with this new release, I started by trying various methods to get the image into the post by cutting and pasting various bits of HTML and JavaScript from the fireworks .html source file. The most important thing to remember is that you need to include Macromedia’s JS functions in the header of your theme, as high up in the code as possible, but at least before the CSS. What you’ll need looks like this:

Hiding JavaScript so that visitors can’t see it might not seem like a necessary precaution to take in most web programming situations. After all, a server-side language like PHP automatically prevents users from seeing your source code, and increasing functionality is quickly rendering the client-side advantages of JavaScript less significant by the day. However, there are many practical reasons to take the PHP-hidden-JavaScript approach, especially if you have long and complicated scripts that already exist and are in use, which would take a significant time commitment to revamp in PHP.
The key to this approach is to encapsulate your JavaScript in a separate PHP file, and to use a PHP session to restrict access to those scripts except when you want it to be explicitly permitted (i.e. when you want to run them from a specific page). To accomplish this, we first create a PHP session on the page from which we want to run the JavaScript.

< ?php
session_cache_limiter('none');
session_start();
if(!$_SESSION['allow_script'])
{
$_SESSION['allow_script'] = true;
}
?>

Placing this PHP at the top of your page opens a session and registers the variable ‘allow_script’ to that session, with a value of ‘true.’
The next step is to move whatever JavaScript you want to execute over to another file called ’script.php’ This file should contain your JavaScript wrapped in a PHP tag, along these lines:


< ?php
if(!$_GET['allow_script'])
{
session_start(); //restart the session from the previous page
}
if($_SESSION['allow_script']) //execute the javascript only if the variable is passed
{
header("Content-type: text/javascript");
?>
alert(”Hello World! JavaScript executed.”);

This portion of the PHP guarantees that the JavaScript generated by it does not appear to the end user, even if they navigate directly to script.php. The $_GET['allow_script'] check insures that the user is not trying to do an end-around by passing the allow_script variable with a value of ‘true’ directly to the script.php page, which would obviously allow them to view the JavaScript source.
Finally, you need to unregister the variable and close the session:


< ?php
$allow_script = false;
session_unregister('allow_script'); //delete the variable from the session
session_unset(); //make the session inactive
session_destroy(); //and toast it for IE
}
?>

NB: session_destroy() is not necessary for Firefox or Internet Explorer 6 or better, but leaving it out means that IE 5 users will be unable to reuse the script.php page without closing and re-opening the browser.
The end result of this simple process is a nicely hidden, encapsulated JavaScript that can be called with the simple line:

<script language="JavaScript" src="script.php">

Now your existing JavaScript (with all its client-side capability) can be easily referenced within your code, without leaving it vulnerable to the malicious efforts of prying eyes.