singularityconcepts.com

Add an MP3 Player to EasyBe

Sat, 29 May 2010 09:42:53 GMT

I recently worked on a project which, among other things, involved implementing the "easybe 1-2-3" music store software (basically, it's a pretty simple-to-use platform for managing for-sale music downloads).

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:

This text will be replaced by the flash music player.

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:

   // Send the headers
   header('Content-type: text/xml');
   header('Pragma: public');
   header('Cache-control: private');
   header('Expires: -1');
?>
'); ?>

0): ?>


       public/demos/
       <?php echo $row['title']?> - <?php echo $row['artist']?>



Nothing 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.

Font Problem...Resolved!

Wed, 19 May 2010 09:22:03 GMT

Recently, one of my clients sent me a purchased font in the dreaded .dfont format (.dfont is how Macs save fonts...it stands for "Data Fork Font"...dumb!). While this is nice on Macs [several fonts can be bundled in one .dfont file], it's not great for a PC because, well, Windows has no idea what to do with it.

Fortunately, Google provided an answer pretty quickly. Apparently, there's a nifty little bit of freeware out there called DfontSplitter. If the name isn't obvious, DfontSplitter basically breaks up the .dfont file from the Mac and converts it into individual True Type Font files...these Windows understands :)

So for those of you out there who have a Mac and are making fun of me for my lack thereof, bite me! For those that are in the same boat as me, check out DfontSplitter--it pretty much rocks!

Quick connectionString Epiphany

Fri, 14 May 2010 08:47:29 GMT

Ok, if you're like me and aren't the smartest cookie in the jar, something like specifying a connectionString in a web.config file can be maddening. Of course, it doesn't help that there are literally 123 billion possible ways to do a connection string...but I digress.

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 :)

SharePoint 2010 is Official

Wed, 12 May 2010 07:14:10 GMT

Readers of this blog no that I am no fan of Microsoft. However, I am actually kind of excited about the official launch of SharePoint 2010 today.

Previous versions of SharePoint were okay...actually, they were pretty limited, extremely clunky, and revealed Microsoft's blatant desire to give the finger to everyone not on "approved" (read Microsoft-developed) platforms.

Well, 2010 reverses alot of this. The architecture has been reworked, so sites in SharePoint actually bear some resemblence to web standards. User interfaces have been SERIOUSLY upgraded so that managing content is more enjoyable and less like oral surgery.

But perhaps the coolest part of 2010 is that there is truly deep interaction with the full suite of Office products. From Word, to SQL Server, to Visual Studio, it seems that every single Office app has really meaningful hooks into the core of what SharePoint does. What does this mean? Well, Office is now no longer something you have on your crappy work PC...with SharePoint 2010, it's the power of the Office Suite available anywhere you might be.

New Spry Enhancements

Sat, 01 May 2010 06:28:28 GMT

Even though I've pretty much given up on Adobe's Spry Framework, I noticed yesterday that some major updates have been added in, primary among them the introduction of Spry UI. According to the Spry Team's blog post, Spry UI is a new way of approaching Spry widgets that moves away from the previous (and kind of annoying) necessity of following a prescribed markup model and now attempts to work with user-defined patterns. This *should* allow for much more flexibility and customizability, and allow for much more robust opportunities for skinning that were previously possible. Moreover, because all the widgets will now inherit from the same shared base classes, the door is widened for Spry to become a much more robust framework in the future.

Does the introduction of Spry UI mean that Spry development is alive and well, and that Adobe is committed to making something of it long term? Only time will tell.

The problem for me, of course, is that time is precisely the problem. Development of the framework has been seemingly eternal, and significant updates (whether features or simply information about ongoing development) are VERY infrequent. While I see a lot of promise in what Spry can do (and can become), "facts on the ground" force me to use other, more mature frameworks for serious development.

I don't mean this as a slight to Spry, nor to the talented Spry team (or even the thousands of developers who make really good use of it). The bottom line for me is that I need a framework today that has the fully formed features of a jQuery or Ext. If Spry Framework is in that position tomorrow, I'll more than happily give it a another chance.

Quick JavaScript Goodness

Sat, 10 Apr 2010 10:48:12 GMT

Ok, so this is nothing new nor is it something that hasn't been blogged about before. However, I thought I'd share in case it helps some other googler that can't find what they're looking for :)

So in JavaScript, most functions have a pretty standard form: you name the function and then define which arguments you wish to pass to the function. Depending on how you work out the logic in the remainder of the function, the arguments can all be required, all be optional, or whatever.

The one major drawback, however, is that the arguments must be passed in the proper order. For example, if I have a describeMovie() function that takes an actor, title, and year argument, the order I define these arguments in will be the order in which I have to pass them in my function call.

function describeMovie(actor,title,year) {
    // alert the movie’s lead actor
    alert(actor);
    …………
}

would require

onclick="describeMovie('Bruce Willis','Surrogates','2009')"

in order to work properly.

(This won’t work:)

onclick="describeMovie('Bruce Willis','2009','Surrogates')"

Also, while I can easily pass the actor and title parameters without the year parameter (describeMovie('Bruce Willis','Surrogates')), I’ll run into issues if I try to pass just the actor and year parameters (describeMovie('Bruce Willis','2009')), for the order in which they are passed will make my function think that what I want to be the "year" parameter is actually the "title". Lame.

Usually, the answer is just to pass an empty placeholder parameter in order to "skip" an unneeded parameter. While this works, it can be a bit unreadable if you have a butt-load of empty parameters…wait, is the eighth set of '' for this or is the thirteenth…?

But honestly, the biggest problem is that the correlation of "Bruce Willis" to the parameter "actor" is only defined by order. There’s nothing beyond this that binds the two together.

Is there a way around this unsavory state of affairs? Of course!

Instead of passing x number of arbitrary, unnamed arguments to the function, you can actually pass an object literal as the only argument.

Now of course, an object literal is nothing special. It’s just a simple collection of name-value pairs. But here’s where the coolness of this approach is realized. Because we’re using name-value pairs, not only are the values we’re passing “named”, but we can also use them in any arbitrary order that we want to, precisely because they’re named!

So in our example, instead of having to invoke our function like this:

describeMovie('Bruce Willis','',2009) [remember, the empty title?]

With an object literal we can do this:

describeMovie({actor:'Bruce Willis',year:2009})

To me, the second is much cleaner and more intuitive. We're only passing what we want to, and not forcing the issue with empty, placeholder arguments. Moreover, I feel like I have more confidence in how arguments are passed, since they are now "named" in the object literal.

On our actual function, then, it’s equally easy to deal with using the object literal, especially now that everything is wrapped in name-value pairs:

function describeMovie(obj) {
    // alert the movie’s lead actor
    alert(obj.actor);
}

Super nice!

Update Miscellany

Mon, 29 Mar 2010 07:20:06 GMT

Wow, it's been far too long since I've posted. I've been quite busy as of late, and have been putting the finishing touches on a couple of pretty decent sized projects.

But perhaps most interesting to followers of this site is the fact that I'll be working with a friend of mine over the next couple of months to completely revamp a site that we think will be pretty sweet in a couple of months. But the coolest part is that we're going to be creating this site--as much as possible--using exclusively ColdFusion ORM. As we make progress, I'm going to do my best to regularly blog about our experiences as we tap into this extremely cool technology that is available in CF9.

So anyway, stay tuned...I hope to have some killer posts up very soon :)

Ext JS Screenshot Fun

Tue, 02 Mar 2010 22:51:34 GMT

Quick (ok, not really) video about some screenshot croppin' goodness with Ext.

Check it out, and become my Facebook friend while you're at it!

Here's the super-fly video

ColdFusion and ORM...Yummy!

Tue, 02 Mar 2010 05:33:43 GMT

The other day, I was flipping through the ColdFusion docs (yeah, super exciting!) and came across the section about ColdFusion's support of ORM. If you're not familiar with it (I wasn't really until a few days ago), ORM stands for "object-relational mapping." While it sounds a bit overly technical, ORM is basically a way to interface objects in code to relational databases that levels the playing field, allowing your code to be more or less agnostic about what kind (or kinds) of databases that it's connecting to.

At first, I was unimpressed, but then I took a few moments to think about it. How often have I had to switch between database systems? Plenty. And how fun was it to have to go back and rework my code to account for the differences in typing and syntax? It wasn't. With ORM, however, alot of these headaches are removed because you can create an abstraction layer in your application using ORM to not really have to worry about what datasource you might be connecting to.

Now obviously, the subject of ORM is much more complex than my admittedly weak description. However, after a lot of reading I feel like I have a decent idea on what the approach is, at least, so I decided to try my hand at a little ORM development.

As with most things, ColdFusion 9 makes ORM development stupidly simple. Utilizing skills that you already have, you can make a few tweaks here and there and have some seriously cool ORM action up and running in a matter of minutes.

So let's look at some of the peices.

First, in Application.cfc, you have to turn ORM "on" and tell CF which datasource you want to use for this ORM voodoo. This is accomplished pretty easily:

this.ormenabled = "true";
this.datasource = "my_test_orm_db";

Next, you'll want to start creating some CFC's--something tells me you've done this before :)

But before we do that, the CFC is going to be a bit different than it might otherwise be. Rather than creating a collection of functions and properties that are just kind of grouped together, this CFC is going to be created for the express purpose of describing a data object. It's going to be the interface for how our ORM app colludes with the database.

component persistent="true" {
    property name="jobid" generator="increment" fieldtype="id" ormtype="integer";
    property name="title" ormtype="string";
    property name="description" ormtype="string";
    property name="startdate" ormtype="date";
    property name="enddate" ormtype="date";
    property name="datecreated" ormtype="timestamp";
    property name="lastupdated" ormtype="timestamp";
}

In this example (done completely in cfscript, btw--thank you CF9!!), I create a component like normal, but add the attribute "persistent" to it. This attribute will tell ColdFusion to persist this object (which is really like a dataconnection to a particular table in your db) in the application so that you can interface with this object to perform your run-o-the-mill CRUD ops.

After creating the component, I simply add a property for each column in my table that will be the "maps" that ColdFusion uses to interact with the database.

Ok, so once this object gets persisted in the application, ColdFusion is going to do something terrifically cool. For this object, it's going to create a bunch of standard methods that can be used for retreiving information about the object, updating it, creating new objects, and even deleting it. Additionally, it's going to create getters and setters for each property for super-easy retrieval later on.

So let's see how this plays out. Let's say that I want to create a new "Job" record in my "jobs" table in the db. Before, I probably would have created a component for "jobs" and added a method to it called "createJob." CreateJob() would have taken some arguments, and then performed a query to the db...pretty

standard stuff. With ORM, however, this is more or less ALREADY READY TO GO now that I've finished defining my data object.

Now, I can simply do the following (this is on a non-cfc page where I have a form action or something):

Here, I create a new instance of my "jobs" object with EntityNew(). Again, EntityNew() was auto generated by CF--I didn't have to worry about it. Next, I simply set the value of each property of my object that I want to create using set(). And again, the method is auto-created by CF. Once I've set all the properties that I want for my new object, I can simply commit it and save my object using EntitySave(), yet another auto-generated method.

And...that's it. If I check my database table, I'll see that a new record has been added with all the values that I applied to the object that was created and saved.

Now if you're like me, and are still kind of mired in older-school ways of thinking about data connections, this can be a trip. After all, where the heck is the query?!?! But that's the beauty of ORM. After defining the properties of my data object, I don't have to worry necessarily about SQL syntax to get data into and out of my database. Rather, I can use the definition I've created about my data to interface with the database and be happy and healthier for it.

So over the next several weeks, I'm going to be experimenting alot more with ORM, and hopefully will post some more thoughts. But before I go, let me share my initial impressions.

One of the big reasons I like this approach is that it really forces you to start thinking in a more object-oriented manner. Of course, ORM is no magic bullet for developing an OO app, but I think the way in which it makes you think about your data is a very strong step in that direction. Secondly, and related, I like that it turns data into objects. In other modes of programming, it's very easy to get very lost in patching together code here and there to get something functional. However, this approach really makes you think about the connections that your data have with one another, and I think helps to guide the way in which you approach developing an application in order to support these relationships.

Of course, I have very limited knowledge of OO, so I might be way off. However, I feel like this is a move in the right direction, so let's see where it leads :)

Ext to ColdFusion...Nice!

Sun, 21 Feb 2010 09:38:53 GMT

So I know a lot of the posts I've been writing recently have been about stuff that's been around a while--Ext helper functions, CFScript, etc. Nonetheless, I post them because some of the answers to questions I've found in developing solutions have been less-than-easy to find, so perhaps repeating some of the same things again will help Google find it a bit easier for someone else someday.

On with redundancy!

Obviously, JSON-related technologies have been around for a while, and with ColdFusion 8, a lot of native JSON handling was added for the creation of some sweet AJAX-y goodness. While I've dabbled with these, I've never really had a need for them...until now.

I recently developed a remote CFC function that required about 12 different arguments. On the client side, I also developed a quick EXT Ajax.request() method to pass these arguments into the CFC function.

Now with Ext, it's incredibly simple to pass arguments to server-side functions, as this example illustrates:

Ext.Ajax.request({
    url: 'com/functions.cfc',
    success: successMethod,
    failure: errorMethod,
    headers: {
        "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8"
    },
    params: {
        method:     'setupLife',
        argument1:     arg1,
        argument2:    arg2,
        ...
    }
});

I like this alot, because it allows me to treat each argument as its own "thing," rather than stringing together a bunch of "&argument1=arg1" in the query string.

But what if want to treat several arguments as a group? For example, there are several times where I create arrays or objects in JavaScript, and then want to use the values in these arrays or objects as arguments for my remote function. Like this:

var person = new Object();
person.name = 'Joel';
person.hobby = 'Philosophy';
person.favband = 'Emery';

If I were to pass individual arguments, I'd have to break out each of these properties and assign them to arguments--lots of duplicated work, and it sorta breaks the natural relationship these arguments had to each other natively as a JS object.

Fortunately, EXT and CF together make this super easy.

First, the EXT side. Instead of breaking out my "person" properties into indivdual arguments, I can use the handy JSON-encoding capabilities of EXT to treat this object as what it is--a collection of related properities:

Ext.Ajax.request({
    url: 'com/functions.cfc',
    params: {
        method:     'setupLife',
        argument1:     arg1,
        argument2:    arg2,
        ...
        person:        Ext.encode(person);
    }
});

As you can see, by JSON-encoding the object I already created in JS, I can treat the full object as an object, and pass it as a single argument to my remote function.

What is super cool about this, however, is what happens on the CF side. Because I'm passing my person object as an object, I can now retrieve the object with CF and treat it as an object within CF.

Here's my function:


    ...
    
    
    ...

This function requires the "person" argument, which you'll remember is what we JSON-encoded on the JS side of things. Now that we've retrieved the argument, we can use CF's deserializeJSON() function to transform the JSON object which is passed as an argument and convert it to a CF structure.

The super-sweet part about this is that once we run this function, the JSON object will become a ColdFusion structure, and we can do whatever super-bad juju we want to do with it, not having to worry about what format it came to our function in. Awesome.

So that's it. With Ext and CF, you can do some really nice things very easily, and don't really have to worry a whole lot about messing around with data conversion between the client and server.