Refactor 2.0 and the future!

Refactor 2.0 and the future! [Tuesday, 30 August 2011 22:25]

Written by Dan Brown

Version 1.2.6 is now pretty much ready, just got to do some final testing and get the upgrade/install up to date.

Refactor

One of the biggest things this release is behind the scenes in the form of a refactor. We did this before way back in May 2009 but code drifts and it was starting to get painful to change things and add new features again. About four months ago I decided to try and rejig one of the JavaScript files as it was getting a bit unwieldy. So I checked out the code into a separate directory and I ended up changing so much (pulling all callbacks into a single method, moving to jQuery, switching to JSON as the AJAX comms system, etc) that I just had to go ahead and change all the other JavaScript files to match.

This is what delayed 1.2.5 a while and just when that was done and we were going to merge it into the main branch to release... I decided that the main PHP classes had to be done as well. So we just pushed out the new features by themselves and left the refactored branch to wait for 1.2.6.

The main classes were a bit of a mess to be honest. We had a class for example called Gallery which dealt sometimes with one gallery and sometimes with several, and a bunch of gallery related functions outside the class. Now Gallery deals with just one gallery at a time and is persistent for the page generation so fewer database hits. The functions for dealing with multiple galleries are moved to static methods in the Gallery class to use it's namespace. The same goes for the Image, User and Tag classes. It is so much nicer to work with now and easier to add new stuff.

Just wanted to say why the previous release and this one have had a delay that their features don't reflect. Although we have 2 good new features in 1.2.6, you'll have to wait until the release announcement to see what :)

Future plans

Now thinking ahead to 1.2.7... Just one weekend before I decided to hit the JavaScript code four months ago I spun off another branch of the code to start what is to be the main new thing in 1.2.7 - URL rewriting. It mostly works in that branch so should be quick to put into place. It means that instead of the current ugly URLs such as http://www.somedomain.com/gallery/index.php?action=image_view&image_id=33&parent_id=54 we can use http://www.somedomain.com/gallery/my_holiday/Brazil/some_cliffs. Much nicer to work with and may help some towards Google Images starting to index your pics as viewing the full image also includes the original filename (which can be customized). The old URLs still work so it won't break bookmarks or links. We have a few other minor bits penciled in for 1.2.7 but I wouldn't be surprised if we can fit in another nicety as well.

1.3.x we also have been having some plans for. We had decided a long time ago that we need a better way to administer images and galleries without jamming more and more JavaScript into the main pages like we have now. 1.3 has been earmarked for this part for a long time. Exactly how we weren't sure of but it would be based around a gallery and image manager on the admin pages to see everything in one place. This should allow things like re-ordering, choosing the pic to use for gallery thumbnails and seeing errors all in one place. A few weeks ago we came up with a solution that will complement this focus on better admin which is to split Moa into a front and back end much like Wordpress and CMSes do. Being able to separate the admin code entirely makes adding user features simpler as we don't have to worry about breaking admin code while we do it. The templates especially can be so much simpler as they don't have to reserve space for admin features or feedback at all. We can also add some CMS-style abilities like turning on and off the features you want without you having to mess with the templates themselves.

The stated goal of Moa is be a gallery that is simple enough for anyone to use and not just pile on the features. We do have to balance that with ease of maintainability and although we have been heading down the all-in-one-page editting route a-la Google docs/mail I think that this separation is a reasonable tradeoff for the usability and faster turnaround we should be able to get from it.

There is one major strike against Moa in that ease-of-use department which we also have a solution for in mind. It's not something we can talk about yet though and will be a lot of work to implement. We do try to keep Moas goal in mind though with every release.

Any thoughts? Leave a comment.

Comments

Add New