Archive for February, 2010

I’ve been accused, in the past, of re-inventing the wheel because rather than grab already created packages for scripting, I like to try to do it myself from scratch, if I can. The efficiency of my approach was proven yesterday as I searched for a way to make text boxes grow the way they do on Facebook.

I looked at the HTML on Facebook, and they used a keypress event to run a function, which was on a separate page that I didn’t want to hunt down. So I used Yahoo to find examples of scripts.

I found one that used jQuery (55k of code if you get the minimal version), plus an additional external script (about 60 lines of code) to do the job…except it wouldn’t work on my site (worked in the demo on the source site).

So I looked through the code to see how they did it, and discovered it was some serious overkill.

I was able to accomplish what they used tons of code to do just a few lines of code.

Here’s the result…

<textarea name="description"
 style="height:28px;overflow:hidden;"
onKeyUp="
if((navigator.userAgent.indexOf('MSIE')>-1) |
  (navigator.userAgent.indexOf('Opera')>-1))
    {
    this.style.height=(this.scrollHeight+14)+'px';
    }
  else
    if(navigator.userAgent.indexOf('Firefox')>-1)
      {
      this.style.height=(this.scrollHeight)+'px';
      this.style.paddingBottom='0px';
      }
    else
      {
      this.style.height=(this.scrollHeight-8)+'px';
      }
  if(this.scrollHeight<28){this.style.height='28px';} "
cols="20"></textarea>

…the part in red is the code that does the work, and the “overflow:hidden” part gets rid of the scrollbar. And here it is in action…

Write something here…

So by ignoring the prepackaged code I was able to accomplish the same result with just a fraction of the coding used by the “re-invented wheel”.

Some times the wheel needs to be re-invented.

UPDATE: Forgot to check browser compatibility. The code above now displays some simple compatibility changes for the way different browsers render the code.

I haven’t seen them quite as much lately, but corner banners were really popular for a while. You can see one in the upper left corner of my main blog JackLewis.net.

The first step is to get the image. You’ll want it to be no bigger than around 150×150 pixels.

Here’s how I do it in Photoshop…

File>>New>>

Now use the Rectangle Tool to make a rectangle, wider than the image.

Now use Edit>>Transform Path>>Rotate and rotate the rectangle until it can touch the top-right and bottom left corners…

Apply the following Effects…

Create your text and do the Edit>>Transform Path>>Rotate thing again to make it line up with the rectangle. It should look something like this…

Click File>>Save for Web & Devices. Set the Preset to PNG-24 and make sure the Transparency box is checked. Click Save and title the image and set the “Save as type” to Images Only (*.png). And save it.

And it should look like this…

The next step is to get it up into the corner.

The code you’ll use is…

<div style="float: left; position: absolute;
left: 0px; top: 0px; z-index: 1">
<img src="[url to corner banner image]" border="0"
alt="[Message to display when mousedover]"></div>

…except replace the parts between the [ ]‘s with the appropriate data. You can also add a link if you want, like this…

<div style="float: left; position: absolute; left:
0px; top: 0px; z-index: 1">
<a href="[my link]" target="_blank"><img
src="[url to corner banner image]" border="0"
alt="[Message to display when mousedover]"></a>
</div>

And that’s how it’s done.

First of all I’m using the broader definition of hacking. I don’t mean illegally breaking in to. I mean to use programming expertise to glean more functionality out of.

Movable Type published static pages (HTML) from the information you provide and re-publishes those static pages whenever it detects a change (a new post, a comment, etc.)

However, it’s possible to also include some dynamic content. The first step would be to change the type of page from HTML to PHP (or whatever scripting page your server runs, that you know how to use).  To do that log in to the MT dashboard and go to Preferences>>Publishing and under Publishing Options change the File Extension for Archive Files to php (or whatever extension is used for the type of script you’ll be using.

Then go to Design>>Templates and change the filenames on all Index Templates so they’ll have the correct extension.

To give a simple example we can change our individual posts to only output the comments when the comment link it used. First make sure that the comment permalink is there in addition to the usual permalink, and the comment permalink has ?comments=yes#comments on the end. (the comments=yes sets a variable we’ll use with the script. The #comments directs the browser to the top of the comments)

Go to Archive Templates and then Individual Entry Archive.

Find where the comments start. It should be a div that looks like…

<a name="comments"> </a>
   <MTIfCommentsActive>
   <div id="comments">

…just above it add the following…

<?php
   if($_GET['comments']=='yes')
     {
?>

…Now we’ll look for the end of the div. This can be pretty hard since typically ending divs are not marked. But, it should look something like…

</MTEntryIfCommentsOpen>
 </div>

Right after it insert the following…

<?
  }
?>

Once this is done, republish the archives.

Now when someone goes to the individual post using the regular permalink, the comments won’t appear. It’ll only be when they click on the comments link that the page will reload, and show the comments. This will save some bandwidth by not showing comments unless someone specifically wants to.

Obviously this blog is done on WordPress. My other active blog, JackLewis.net is done on Movable Type. My wife’s blog, Linda’s Thoughts (which I set up for her is also on Movable Type).  I’ve worked extensively with both, so I feel I can look at the pros and cons objectively.

Movable Type is the older platform, initially released in 2001. It’s based on Perl and provides static page, rebuilt whenever any change is made to the content.

Word Press is somewhat younger, starting in 2003. It’s based on PHP and generates all pages dynamically.

Having programmed in both Perl and PHP and can tell you that while Perl is a more flexible programming language for the expert, PHP comes very close, and is much, much easier to manage. So unless you plan on never, ever having the code tweaked, (or  have someone handy who knows Perl very well) PHP is the better choice of the two.

The reasoning behind Movable Types static/rebuild method is that the server would do less work. In reality it turns out to be just the opposite. I’ve done several MT=>WP conversion of larger blogs because the CPU simply couldn’t handle the massive rebuilds required. However, on some of those rebuilds the client later asked about a caching plugin, to further reduce CPU usage, and Movable Type offers a dynamic option–one which I’ve never been able to get to work–however.

Both have excellent backend management systems, as well as tons of plug-ins to expand the functionality of the scripts.  Installation is equally difficult on both (or easy, depending on your perspective) and the available templates are equally attractive, however I seem to find more WordPress templates available than Movable Type.

One big factor for me, however, was my purchase of Artisteer, which can create WordPress templates very easily. In all honesty the templating creation process for both left a lot to be desired, from a designer’s standpoint. Artisteer put WordPress far ahead.

I’m still battling WordPress’s bad habit of doing funky things to some text, something which has affected me, many of my clients and others seeking help. I never had that problem with Movable Type.

So there are the pros and cons. That should help you make the decision for your needs.

Among the things the reader’s browser will need to load for the main page of your blog are quite a few elements that won’t change very often. Blog rolls, style sheets,  javascript, etc. Browsers will usually request the modification date of the file they need, first, and if it’s older than the one stored in the browser’s cache, use the cached version. That not only saves you bandwidth, but speeds up the load time.

A lot of blogrolls are handled from other sites, but some are placed right on the page. Take any blogrolls you manage yourself, and convert them to javascript, put then in an exterior file and load them separately. That actually much easier than it sounds.

Lets take an example blogroll. Here’s what the html might look like…

<a href="http://blogscripting.com">BlogScripting</a> <br>
<a href="http://jacklewis.net">Jack's Blog</a>

To change that to javascript we simply do the following…

document.write('\
<a href="http://blogscripting.com">BlogScripting</a>\
<br><a href="http://jacklewis.net">Jack\'s Blog</a>\
');

Notice, we put the code inside a “document.write(”);” and we put a backslash in front of any line breaks and in front of any apostrophes/single quotes (other than the two on each end of the text.)

We’d then save that text to a file…let’s call it blogroll01.js…and call it from the HTML (put it in the code where the blogroll was)  like this…

<script src="blogroll01.js"></script>

Now when the page loads, that part will be loaded from a separate file, and inserted into the page. The next time the reader looks at that page, or any other page on your site that uses that blogroll, their browser will load the blogroll from their cache, instead of from your server. Typically the cache would refresh every time they opened a new browser, so the next day they’d load a fresh copy, but use that when visiting other pages on your site.

Your CSS styles should also be external as should any javascript you need for your page. This will do wonders at speeding up the load time as well as reducing bandwidth.