Add cool stuff.  Like Pay-Pal plugins.  Like RSS readers.  Like Firebug.

It was the bees’ knees, and looked like it was going to gobble up all the stragglers that IE left in its “who cares about the experience” attitude toward the internet.

But then Chrome came along.  It was sleek.  It was fast.  And best of all, it brought some fresher-than-Firefox ideas to browsing.

Better, fresher ideas.  Like tabs-on-top.  Like better architecture for faster…everything.  Like not-having-to-upgrade-every-2.5-seconds.

So I’ve been using Chrome alot lately.  Sure, it’s different.  But what I’ve found is that it’s better.  Sure, it doesn’t have Firebug (which is probably the only reason whatsoever that I continue to use Firefox).  But every version gets better.  And faster.  And awesomer.

And Firefox?  Perhaps its my groaning, Vista-laden PC, but Firefox hates everything.  It’s slow, it freezes, it crashes…and very few of the plugins that I depend on for Firefox to be awesome can keep up with the releases.

And the things I’ve been seeing for v4 are less than impressive.  The other day I watched a video on their “new” feature for 4–tabs on top.

Tabs on top.

Hmmm…where have I seen that before?  Oh yeah, every other browser to update its version in the last 6 months.

Now in all fairness, tabs on top makes sense, and the logic in the video–IMO–is pretty well founded.  But it just feels like a lot of far too little and way too late.

Obviously, I’m going to keep using Firefox in some capacity.  There’s the perennial issue of cross-browser compatibility that I always have to wrangle for my work, and Firebug still destroys Chrome’s girly development tools. However, I see our paths steadily diverging, and see little opportunities for them to entwine again.

In HTML5, this becomes a reality. Enter Server-Sent Events. In a nutshell, server-sent events “enable servers to push data to Web pages over HTTP or using dedicated server-push protocols.” This means, basically, that the client doesn’t have to keep asking for information: the server will notify the client when new information is available.

In it’s present state, server-sent events are only available for Opera and Chrome (6) dev releases. Additionally, they are currently implemented in two different ways. For Opera, the technology utilizes a DOM element (), while Chrome is entirely JS based. For this overview, I’ll be concentrating on the Chrome implementation.

For the example I worked up, I’ve created a simple chat interface. The basic idea is that two people share usernames, entering them into their respective client interfaces. When each chat message is sent, the record is saved to a database on the server, and an independent page continues to query the db for new data pertaining to the chat session. If new data exists, it pushes it to the clients’ interfaces.

The Code

So first things first. Let’s create our EventSource, the base object that we’ll utilize to make the magic happen:

serverevent = new EventSource("serversent_helper.cfm");
serverevent.addEventListener('message', onMessageHandler);

This is easy enough to see what’s happening. Basically, I define a new EventSource, and pass to it the server-side page that will manage the pushing of data. Finally, I add a listener to the “onmessage” event of the EventSource, which then in turn calls a user-defined function to do whatever with the data from the server (an event object is passed in the callback method).

That’s it. Seriously, pretty simple. From here, the rest is basically getting the data from the server to be in the proper format to work with the EventSource. And this is where it gets a little murky. Per the spec, the data pushed from the server has to be in a very specific format. To be honest, I spent more time than I’d care to admit on this. But it was a good lesson.

There’s a lot in the spec about this, so I’ll only cover the most important details. This is from serversent_helper.cfm, the source specified in the EventSource invocation:

           writeoutput("data:"&serializejson(message)&chr(10));
           writeoutput("id:"&qmessages.messageid&chr(10));

What I’m not showing you is the queries I used to create and retrieve data from the chat sessions. Assuming that a chat to be pushed exists, this is the code that generates the data pushed to the client.

First, notice the content declaration of “text/event-stream“. This is incredibly important. If your content is not in this format, the push from the server will not work.

Next, notice the output sections. Per the spec, data pushed should be in the following format: “data: [string]“. It is the combination of “data:” and an accompanying string that makes the push work. Without it, nothing will happen. Following the “data:” declaration, I’ve also set “id:”. This is important because you can optionally tag each push with an id which will then be subsequently passed as a header in future interactions between the client and server. Specifically, the header “Last-Event-ID” will be used, so if a connection is lost, the last-used id can be processed when the connection is restored, picking up where it left off.

Finally, notice the newline characters at the end of each line (“chr(10)” in ColdFusion, “\n” in other languages). This is EXTREMELY important because the “field names” of the response are processed on the basis of the newline characters. In this example, if I did not put the newline character after the “data” block, my response would look like {…jsonstring…}id:numeric, rather than just {…jsonstring…}. Additionally, the Last-Event-ID would not get set.

And yes, you can use JSON, so not problems at all pushing complex data objects

Additional Methods and Considerations

I didn’t use these in my demo, but thought I’d point them out anyway. Besides the “onmessage” event, you can also add listeners to the following exposed events from EventSource:

1. onopen – fires when connection between server and client is created
2. onerror – fires when there’s an error in the connection

And in addition to the url and Last-Event-ID, the readyState attribute is available from EventSource. As its name implies, readyState represents the current state of the connection, and can take the following values:

1. CONNECTING = 0
2. OPEN = 1
3. CLOSED = 2

Wrapping Up

As mentioned earlier, because of the relative newness of EventSource, its implementation is severely limited. However, I think it is a pretty cool idea and I can think of lots of potential uses for this, specifically in relation to connection-less data pushing. I’m excited to see how this develops as the spec is more well-defined and more browsers begin to implement it.

A note about the demo. It definitely works, but there are a few things to keep in mind:

1. It will ONLY work with the latest dev version of Chrome (v. 6). If you try it in any other browser, it will be quite disappointing
2. Because it’s just a quick demo, you’ll have to arrange a chat with someone with the same dev version of Chrome, and you’ll have to coordinate the usernames that you’ll use to try it out, given that the chat sessions are based on user-entered names
3. Sure, I could have made a static example…but I thought the chat would show off the tech a bit more…so sue me!!!

As with the other items we’ve been exploring in our look at HTML5-related technologies, Notifications are really easy to work with.  A word of warning, however.  Right now, this is only implemented in Chrome, and the W3C spec is itself based upon a webkit-specific API.  So in order to make these work right now, you have to use the Chromium API, not the W3C spec.  The fundamental principles are precisely the same (since the latter is based on the former), but has some minor differences.

So now for the obligatory example–let’s get my (or someone else’s…) most recent Twitter post and display a notification.

First, let’s create a reference to the Notifications object:

var notification = window.webkitNotifications;

(Notice the “webkit” syntax)

Now that we have a reference to our Notifications interface, let’s handle the entering and submitting of a Twitter username:

function SetNotification() {
     var username = Ext.get('twitterusername').getValue();
     if(username=='') {
          Ext.Msg.alert('Attention!','Please enter a Twitter username');
          return false;
     }
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          notification.requestPermission(PermissionDelegate);
     }
}

A few things to point out here.  First, as part of the spec, the user has to grant permissions to the service to create Notifications.  Before we actually handle the requesting of permissions, we can check if permissions already exist by invoking the checkPermission() method.  This will return three possible values:

1. PERMISSION_ALLOWED = 0;
2. PERMISSION_NOT_ALLOWED = 1;
3. PERMISSION_DENIED = 2;

To me, the numbering is a bit counter-intuitive (0 == allowed?), but it’s easy enough to work with.

So if we’ve already obtained permissions, we simply call our main function for retrieving Twitter data.  If permissions do not exist, however, we invoke the requestPermission() method.  This will create a browser prompt, and the user can either Allow or Deny permissions for Notifications.  requestPermission() takes one argument: a callback function.  This can be invoked to handle post-permission granting/denying.  In this example, the callback is PermissionDelegate():

function PermissionDelegate() {    �
     // if permissions have been granted (checkpermission()==0), proceed; otherwise, show error message and cancel operation�
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          Ext.Msg.alert('Notice','To receive notifications from this application, please grant permissions when prompted.<br /><br />Please try again.');
     }
}

Simple enough.  If the user grants permissions (checkPermission()==0), we continue with the processing.  If not, we display an error message and suggest that the users tries the operation again.

So on with the example.  I won’t bore you with the process of getting the Twitter post.  If you want, you can check the source code, but it boils down to the nifty JSONP hack…

Now that we’ve been granted permission to create Notifications, and finally have the Twitter data, let’s create a notification!

function TweetSuccess(req) {
     if(req.length) {
          var type = Ext.getCmp('radiogroup').getValue().value;
          var img     = req[0].user.profile_image_url;
          var name    = req[0].user.screen_name;
          var tweet    = req[0].text;
          if(type==1) {
               var tweet    = tweet.parseURL().parseUsername().parseHashtag();
               notification.createHTMLNotification("notification_helper.cfm?title="+name+"&img="+img+"&content="+tweet).show();
          }
          else {
               notification.createNotification(img,name,tweet).show();
          }
      }
      else {
           Ext.Msg.alert('Uh-oh','Sorry, that\'s not a valid Twitter username. Please try again!');
           return false;
      }
}

Most of this function is just getting the values from the returned data, so we’ll skip to the important stuff: createNotification() and createHTMLNotification().

Why two methods?  Well, each provides a little bit different way of displaying notifications, of course!

createNotification() creates a standard, vanilla notification that inherits whatever styles the browser has defined for its notifications.  This method takes three arguments:

1. iconUrl – This is the path (absolute) of the icon that you would like displayed in the notification
2. title – Um, the title of the notification
3. body -  The main content to be displayed in the notification.

While this works pretty nicely, I wasn’t thrilled with the look of the notification.  And although I didn’t pursue it very far, I couldn’t get links or any other styling to show up in the notification.

createHTMLNotifications() picks up where createNotification() falls short in the customization department.  Whereas you pass icons, titles, and body content to createNotification(), you simply pass a url to a page that defines your notification content for createHTMLNotifications().  While this creates a bit more work for arranging icons, titles, and body content, it does allow you to be a bit more creative in how the notifications look.  Plus, since it’s an HTML notification, you can use some nifty CSS3, and who doesn’t love that!

Wrapping Up

There’s a bunch more to Notifications that I didn’t cover (like closing them programmatically, etc.), but hopefully this is a nice introduction to the concepts behind what will hopefully be embraced by all browsers in the very near future.  I see a lot of promise to these, and can’t wait until all the environments are more unified to start utilizing them to their full potential.

As always, be sure to check out the demo (remember, Chrome only ) and let me know what you think.

One of the major drawbacks of this software is that it doesn't come pre-built with a music player.  While it does provide links to file samples that users can download and listen to (way too many steps for 30 seconds…), there's no one-step player for checking out clips from all the songs on an album.  

No fear!  There are ways around this, and in the following I'll walk you through the simple steps to deploy a free, light-weight mp3 player that can play the music you want your visitors to hear.

First, let's get the mp3 player.  While you could use many of the freely-available mp3 players out there, I like the one from premiumbeat.com.  It's super-stipped down and simple to use.  Plus, it accepts an XML file, which will work perfectly for our needs.

Once you have the mp3 player of your choice, go ahead and deploy it on your server.  Don't worry, I'll wait until you're done.

All set?  Excellent.  The next step is to open up the Album Details template file in easybe.  It's in the 123-music-shop/templates/shop/ directory, named something like "albumdetails.tpl".  Why this page?  Well, when this page is active, certain data is exposed via PHP that we can access and pass on to other pages that we'll need to modify.  So for example, on the album details page, an object named "Album" is available, and from this we can access the "id" value, which identifies our album in the database.  (NOTE: I'm not sure this is documented.  I found it out simply by playing around and making good guesses!)

So here's what we'll add to the "albumdetails.tpl" page:

<script type="text/javascript" src="swfobject.js"></script>
<div id="flashPlayer">
  This text will be replaced by the flash music player.
</div>
<script type="text/javascript">
   var so = new SWFObject("playerMultipleList.swf", "mymovie", "295", "160", "7", "#FFFFFF");  
   so.addVariable("autoPlay","no")
   so.addVariable("playlistPath","playlist.php?albumid={$Album.id}")
   so.addVariable("playerSkin","2")
   so.write("flashPlayer");
</script>

Pretty simple.  Basically, we simply initialize the mp3 player (the one from premiumbeats.com, in this instance), passing a dynamic path in our playlistPath variable.  Notice that I'm passing {$Album.id} — this is id of the album I mentioned before that is exposed.

Ok, so we're almost there!  All that's left now is to generate the XML that will build our playlist and feed the mp3 player.

Now go ahead an open up a new file.  I creatively named mine "playlist.php", but feel free to be more generic if it suits you

In this file, we need to do a couple things.  First, we need to evaluate the "albumid" that we pass through the URL query string.  Next, we need to query the database to get all the songs for the albumid that we've passed.  And finally, we need to generate some XML that the mp3 can understand.

(I'm going to assume you know how to set up your database connection in PHP, and hopefully you also know how to parse out the query string.  WIth that assumption, let's move on to the database query.)

So one of the odd things about easybe is their db structure.  Rather than storing info about albums, songs, etc. in a flat, relational way, they store the data in an almost key-value pair (or trio or quad…) manner.  While not impossible to work with, it can make getting at the data a little less that straightforward if you're not used to seeing this kind of thing.

For example, 1 song in the "productav" table spans at least 7 rows, producing a structure like this:

ID    Name                        Ord        Value
1     artist                   NULL     Seth Condrey
1     title                     NULL     Jesus Paid It All
1     running_time        NULL     5:17
1     free_download      NULL     true
1     song_file_name    NULL     Jesus Paid It All_1.mp3
1     demo_file_name   NULL     Jesus Paid It All 30sec_1.mp3
1     single                  NULL     yes

Obviously, a regular relational approach will not serve your queries very well!  Of course, there are several ways to accomplish the desired result, but here's the final query that I arrived at:

select     p.id,
    (select value from productav pv where name = 'artist' and pv.productid = p.id limit 1) as artist,
    (select value from productav pv where name = 'title' and pv.productid = p.id  limit 1) as title,
    (select value from productav pv where name = 'demo_file_name' and pv.productid = p.id  limit 1) as path
from product p
join bundleproductasm b on p.id = b.productid
where bundleid = $albumid
order by childorder
 
The most interesting thing to note here is the use of the subqueries in the select statement.  If you're not familiar with this approach, what I'm doing is to basically create a faux column of data, based on the results of another query within the scope of the currently executed statement. In other words, I can take the 7 or so rows from the productav table and flip them into a structure that I can actually use.

Ok, so much for mySQL.  Now our last step is to write the PHP code that will produce the XML.  What follows is a very limited approach: you may want to try something a little more robust if you have more extensive needs:

<?php
    // Send the headers
    header('Content-type: text/xml');
    header('Pragma: public');        
    header('Cache-control: private');
    header('Expires: -1');
?>
<?php echo('<?xml version="1.0" encoding="utf-8"?>'); ?>
<xml>
<?php if ($count > 0): ?>
    <?php while($row=mysql_fetch_array($rsongs)): ?>
    <track>
        <path>public/demos/<?php echo $row['path']?></path>
        <title><?php echo $row['title']?> – <?php echo $row['artist']?></title>
    </track>
    <?php endwhile; ?>
<?
ph
p endif; ?>
</xml>

N
othing even worth pointing out here.  A simple loop of the data, and we have some nice XML to spit back at our mp3 player.

And that's about it.  Even though easybe is pretty limited OOTB, it is easily hackable, so adding on some nice little touches here and there are relatively easy and make for a much better product when it's all said and done.

While searching for an answer, I ran across a pretty neat little technique that will make the development of your connection string quite painless.

First, open Explorer, and create a new file. Now, rename the file to X.UDL. Double-clicking this file will open up a Data Link Properties dialog window.

The super nifty thing about the DLP is that you can actually create a full-on connection to a datasource, and test out various settings.  Nice.

But the really beneficial part (well, besides verifying that, yes, this particular service account does, in fact, have access to SQL Server…) is the "All" tab.  Here, you'll see all of the properties of your connection.  While nice information, this is super sweet because these properties are precisely the parameters that you need to enter into your web.config connection string in order to make SQL Server happy.  That's awesome, and a huge time saver if building connection strings isn't something that you do on a routine basis

…

…it was already closed.

…

…hmmm…

Honestly, I couldn't figure out what was going on.  Just to make sure, I recopied the most recent, seemingly correct version. 

No change. 

I went back to the file, made ABSOLUTELY sure that the tag was closed and that there were no weird quotes floating around.

No change.

By now, I was desperate.  I even started commenting out random bits of code around the <img> tag until I was POSITIVE that nothing else was causing this issue.

No change.

Blurg.

Well, it turns out the fix is pretty easy, and it all has to do with the "method" attribute of the <xsl:output> directive.  On my xslt file (which I did not create, BTW), the method was set to "HTML" like so:

<xsl:output method="HTML" …./>

For whatever reason, this method of output can do funky things like remove the self-closing parts of tags.  Dumb.

Anyway, I simply switched the output method to XML and it resolved the issue.  Not only that, but it knocked out about 10 other validation errors that I hadn't even started looking at yet.  Woot!

So if you're interested in learning more about this xsl:output nonsense, be sure to check out the W3C definition…it's a riveting read, but does–at least–provide the right answer

Today I discovered Aptana.  Of course, I've used Aptana before…by used, I mean, of course, that I downloaded the free version and played around with it (especially the built in AIR support).  However, I had never really used it to modify JavaScript.

Well, there is a new love in my life!  Aptana is smart enough to take my JavaScript, spaghetti-code as it is, and self-document all of the functions and variables that I have set.  They may not seem like a big deal, but when you have several hundreds of lines of JS code with inline comments, it can be a big pain to scroll around trying to find this or that.  

With Aptana, this kind of stone-age button pecking is over.  Aptana has a nice, built-in "Outline" toolbar that helpfully shows all of the functions in the selected file, along with any declared variables.  Plus, each function and variable is linked so that you can quickly and easily jump to the appropriate function/variable in an instant.  

Yes, so I am a noob to be just now figuring this out.  But you have to admit, it's pretty flippin' cool

But anyway, the other day we were talking about XHTML validation (you're welcome to start sleeping about right now, if you wish) and how validation fails if there are markup tags that are not "closed" (e.g., a "div" tag that hold an image, text, etc. needs to have a "closing" tag to tell the browser what it's dealing with). 

Somehow, the comment was made that life feels like failed XHTML validation–replete with open "tags" of disappointment that never close…

Boy, I made myself bored just writing this.  Appartently my line of work is dorky and lame.  Oh well.   

One of the things, however, that has always impressed me about the site is how easy and fun to use it is. It features really deep networking capabilities, the tagging is pretty robust, and everything is fast, fast, fast!

Of course, while uploading from the site is easy, I've been waiting with baited breath for them to release an API. Well, recently this happened, and I couldn't be more excited!

The API is alot like Twitter's in that it uses Basic Authentication for user-specific http calls. While not the most secure form of authentication, it is ridiculously easy, especially if you're using ColdFusion whose cfhttp tag has a built in mechanism for managing it.

So tonight, I spent a couple minutes digging into the API, and came away with an easy function for uploading, tagging and providing a description and link for an image. And of course, if you're using ColdFusion, it's cake!

Here it is:

<cfhttp url="http://www.scrnshots.com/screenshots.xml" method="POST" charset="utf-8" username="existdissolve" password="password" multipart="yes">     <cfhttpparam name="enctype" type="header" value="multipart/form-data">    <cfhttpparam name="screenshot[uploaded_data]" type="file" file="#filearea#" mimetype="image/jpeg">     <cfhttpparam name="screenshot[description]" value="#FORM.description#" type="formfield">    <cfhttpparam name="screenshot[tag_list]" value="#FORM.tags#" type="formfield">     <cfhttpparam name="screenshot[source_url]" value="#FORM.url#" type="formfield"></cfhttp>

The function for uploading an image takes 4 arguments, one for the image itself, one for tags, one for the description and a final one for the url (if any). Simple. And the function returns a nicely formatted XML structure that could be used to store upload information, compile tags, etc.

Needless to say, I am very excited about this. Progress on my CSS gallery is coming along, and I am going to hook it into ScrnShots so that all of the featured sites that I add will automatically be populated to ScrnShots, thus boosting my stats on the site. Woot!

Oh, yeah, and be sure to check me out on ScrnShots!

In brainstorming how to make the site better, I suggested that we create a WordPress plugin that would allow others (presumably, CSS galleries…) to grab a feed of our jobs and display them on their site.

So, grabbing my PHP 5 manual (and dusting it off…), I set to work. Fortunately, I have had some recent exposure to WordPress, so I felt reasonably sure that something could be done.

In all honesty, I couldn't be more impressed with WordPress' support for plugins. Consider this: it took me–a complete idiot at PHP–only 3 hours to program then entire plugin from nearly scratch. Not bad.

The beauty of WordPress' plugin support–IMO–is the default database that is so easily exposed. Instead of having to create stupid PHP connections, that stuff already exists, so all you have to do is basically write SQL. Plus, there are a few native functions to WordPress that allow you to use a row (or two) in the default tables for things like configuration data–very handy for simple plugin setup information.

So yeah, this was a great experience and I am impressed with how easy WordPress makes it.

Anyway, if you are looking to display some great web and tech related job listings on your site, check out the plugin. As this plugin is barely above Alpha, I would be very grateful for some suggestions on how to improve it, ideas for new features, etc. And if there are any PHP'ers out there willing to provide some constructive criticism on my code, I'd very much appreciate that!