What’s in a Gallery

We’ll identify the different use cases for our site and then stub out some pages around those. Let’s go over a list of actions we’d like our site’s users to be able to perform. Each of these use cases will constitute a particular workflow that we can complete independent of others.

Task A: Account Registration

For a user to put content on the site, she needs to have an account. To facilitate this we need a page to collect some user details such as an ID and a password, validate those, and create a database entry for the user.

Task B: Login and Logout

Once a user creates an account, he should be able to log in using the credentials provided. We need to display a login form on our pages if there is no user in the session. If the user logs in successfully, we want to display a logout button instead.

Task C: Uploading Pictures

With the preliminaries out of the way, we can focus on adding some core functionality. First, we need to provide a way for users to upload content to the site. When a picture is uploaded we need to create a thumbnail to display when listing the galleries.

Task D: Displaying Pictures

Now that we can upload pictures, we need to display them. We’ll display the thumbnails and use them as links to the full-sized pictures. Since our site is a multiuser one, we also need a way to list user galleries. This way visitors will be able to browse the content from all users.

Task E: Deleting Pictures

Users might wish to remove some of their uploads, and we’ll provide an interface to do so. When a user chooses to delete some pictures, he’ll need a way to select them and then delete both the pictures and their thumbnails.

Task F: Account Deletion

A user may also wish to remove her account; hopefully this scenario never comes up, but we’ll facilitate it just in case. When an account is deleted, we’ll have to remove the user from our database and remove all the pictures and thumbnails for that user.

Code Architecture

Now that we’ve identified what we’d like our site to do, we can begin thinking about how to implement it. To keep things manageable we’ll create separate namespaces for each of our workflows. Grouping all the related actions in the same namespace allows us to compartmentalize the logic.

The first step toward understanding the nature of our application is to consider its data model. Figuring out what data we wish to collect and how it will be used will help us understand the workflow and our use cases. Therefore, setting up our database and creating the necessary tables will be the first step of building our application.

If you’ve worked with a web framework in an object-oriented language, you’re probably used to creating an object model and then mapping that model to the database, either by writing SQL statements by hand or using an object-relational mapping framework such as Hibernate to do that for you.^[45]

In our application the database will be our data model. Because the logic is kept separate from the data in Clojure, there’s no value in copying the maps returned from the database to different data structures. Following this rationale, we’ll use our table definitions as the data model for the application. In a later chapter we’ll cover how we can use a native Clojure domain-specific language to access the database instead.