The Junk In My Trunk

I’ve been wanting to explain how I’m building the new Stock20 site. So this post is about that.

My idea for the new stock20 site is a very fast, user friendly site that not only looks good, but is incredibly easy to use and extremely good at what it does: find music.

I built the current Stock20.com from zen-cart and customized it with flex components and php modules to work as a music store. And it does. Customers love it. The owner loves it. It works. But it has it’s problems. I wont go into most of them here, but one of it’s major problems is how hard it is to manage. It requires a full time web developer to keep it urning, and that is not a feasible solution for the future. So, in comes the new stock20 site.

It has been designed to fix most, if not all, of Stock20’s current problems. Most of them are dull and boring, but the few major ones are worth a few paragraphs.

My basic idea for the new site is a flex front end. The site should never have to “change states”, and it should be a stateless application. Taking that concept further, and using my extensive knowledge of PHP, it only made sense to use PHP for our back end operations. The site as a whole uses a MVC architecture. The model being the database back end. The view being the flex front end. The controller being the php back end.

The php back end is built using WebORB so that it can communicate to flex. It also uses the PEAR MDB2 database abstraction layer. Because php is not tied to any one server (like asp or coldfusion), and coupled with the MDB2 database abstraction layer, this allows the site to run on any server, with any operating system (that php runs on, of course). So other then a few os specific shell scripts, the whole site can run on any server and is therefore, very portable. The MDB2 database abstraction layer supports several databases, including MySQL and MSSQL, and I don’t have to rewrite any code - it just works. Very cool. The php back end is built using a module system that allows most pieces to be changed (or even totally removed) without affecting any other piece. Obviously you can’t remove the MDB2 class and expect the site to still function, but most pieces can be removed without affecting the site as a whole. The Flex front end is built the same way, using modules. When you first access index.php, a MainApplication flex file loads which contains the basic code base to run all of the other flex modules. By it self, it doesn’t provide much visually - just a preloader and then a blank screen. But it then connects to the php back end and figures out which flex modules to load for the specific “page” that was requested. It then loads these, and they appear on the screen. Each having specialized functionality: the MediaPlayer loads and handles all media requests. The SearchTools handle the display of the search tools. The SongDisplayer lists songs found with the search tools. You get my drift. The beauty of using a modualized flex front end is that components can be made to cache on the users computer so that future site visits load very quickly. Also, this caching behavior can be controlled, so that if you edit one of the modules, it loads the newest version from the server automatically.

I’ve been in the process of developing this site for over a year now. I think it would have gone quicker if I wasn’t working by my self, and if I had a full 40 hour week to work on it. But as I said above, our current zen-cart based solution requires extensive maintenance, and that eats up a large chunk of my weekly time. But the site is now starting to come together, and I fully expect to have it at least partially ready for bug testing by the end of the year, if not sooner.

The longest part was building the back end. It was almost as if I was writing my own operating system. And in a sense, I was. The MainApplication has to be able to handle several functions that you normally do not need to even think about when building a flex application. For example, if I want to move or resize one of the loaded flex modules, I have to have a function on the MainApplication to handle it, as the module can not move it self. (It actually can, but this causes a lot of extra code and pointless downloading for users.) Anything that is going to be shared between multiple modules should be loaded with the MainApplication so that the user only has to download it once, and not multiple times. So this required a significant amount of planning and organization on a scale of which I’m not used to. Especially on a one person development team!

So all in all, this project is very massive. If you just need a simple flex site, this is NOT the way to go. But if you need the ability to customize components of your site without affecting the site as a whole, want it to be very portable, want it to be multilingual, secure, fast, and very flexible… a modualized system is the way to go!

I am very excited about the new site. I really can’t wait to get people beta testing it - finding all the bugs I’ve overlooked. I plan to keep posting code snipits of things that I am working on. I think that you can expect within a few days to see some code snipit from our SearchTools module - which will probably be built with several accordions.

So stay tuned!