Again, end of the gallery, not the end of the galaxy.
No apocalypse now.
By end of the gallery, I mean I’ve finished up the backend of the gallery tool.
As outlined in my last entry, I decided to build a PHP/MySQL backend (uses Perl/flat files for front end). While it was a relatively straight-forward process, it was more work than I anticipated – isn’t it always?
And the [intentional] use of MySQL was a bit of a hindrance, but I wanted to use MySQL because it’s the predominant OSS DB out there, and I need more practice on it. And this project is pretty much a good fit for MySQL: Nothing too involved, just some selects and inserts. And all locally, so it’s a no-brainer (yes, perfect for me).
Here’s how the backend project ended up:
- Add/edit gallery page (all at once)
- Edit image name/desc (all at once)
- Add new image/reload existing image (processes and moves file to local and remote server)
- Gallery-to-Image mapping (gallery at a time)
- Include file for header (menu/DB connectivity etc)
- Processing page to generate all necessary TXT files for front end
I used the same CSS sheet as used for the front end (with some back-end classes additions tacked on), so the UI is the same and that’s one less file to maintain (good…).
As far as the database goes, it’s pretty much a trivial exercise – see the code below:
/*list of galleries*/
create table gallery (
gallery_id int primary key auto_increment,
gallery_file varchar(255),
gallery_name varchar(255),
gallery_desc text,
date_added datetime
)
/*image with captions*/
create table image (
image_id int primary key auto_increment,
image_file varchar(255),
image_name varchar(255),
image_desc text,
date_added datetime
)
/*mapping table, images to galleries*/
create table mapping (
image_id int null,
gallery_id int null
)
As you can see, three tables, the last of which is just a mapping table between the first two, so any picture can belong to any number of galleries.
Lots of busy work, but – for the most part – nothing earthshaking.
One of the nice aspects of this project was getting more experience with PHP and files – I’ve done it before, many times, but always separated by large chunks of time. A refresher is always nice.
Actually, it was a nice refresher in PHP, in general. I’ve been working more with Perl and ColdFusion recently, and I keep forgetting about how much I like PHP. And the more of it I learn, the more there is to like.
One new aspect of PHP – for me – was the FTP tools. I’d just never had the occasion to need them in PHP.
When I mentally architected this tool and decided on PHP, I didn’t even know if PHP supported FTP – I knew that it must, and that it probably wasn’t a hack, but I didn’t know. I just assumed that it did, and – if not – I’d just run exec() in PHP to either a shell or Perl script to do the FTP business.
Thankfully, PHP’s FTP tools are as I expected: Pretty extensive and pretty damn accessible.
The two complaints I have with PHP’s FTP functions are the following:
- The syntax is always – GET or PUT – remote, local. I am used to – Unix based – source [space] target. I was hosed on this for about a half hour, until I actually RTFM. Little weird to me, but consistent across the PHP FTP functions, and consistency is good.
- I’m probably missing something, but I don’t see support for MGET or MPUT – each GET or PUT is discrete, as far as I can tell (and, here, I have RTFM). Not a problem in this case for me, as I’m looping through galleries, creating them and uploading them. So it’s a one-at-a-time thing, anyway. But what if I wanted to upload all the JPEGs in a directory? I can’t do a “mput *.jpg .” type thing, as one can with most CLIs. Have to grab list and loop. OK, but still would be nice….maybe in v5
Overall, the Gallery Project was a blast, and it’s turned out well.
I need to do some tweaking – for example, build an FTP function for my MPUT-type needs – but it’s pretty solid and the damn thing actually works!
Time to scan in more pics….