Task E: Deleting Pictures

It’s reasonable for users to want to remove images they no longer wish to display. We need to provide a way for users to select images they wish to remove and tell the application about it. To delete a picture, we’ll do the following:

• Delete the image

• Delete the thumbnail

• Delete the database entry for the image

Since the images can be removed only by the owner, we’ll check if the page matches the user in the session. When this is the case, we’ll allow the user to mark pictures he wishes to delete and submit his selection using the Delete button.

So far, we’ve only been creating static pages. Let’s look at how to add some client-side interaction using Ajax. In this section, we’ll include JavaScript in our page, call our handler using an HTTP POST from the browser, and return a JavaScript Object Notation response to the client.

We’ll use an Ajax call to notify the server of the images to be deleted and update the page to reflect the result of the operation.

First, let’s create a function in the picture-gallery.models.db namespace to delete the image from the database.

Then we’ll add a function in the picture-gallery.routes.upload namespace to perform the three deletion tasks we outlined. We need to provide the function with the user ID and the image name to accomplish its task.

We’ll wrap the actions in a try/catch block. If the deletion is successful, we’ll return ok. If we encounter any errors, we’ll return the error message instead.

Next, we’ll add a handler to handle the deletion of multiple images, along with its route.

There, delete-images accepts a list of names for the images to be deleted. We then grab the user ID from the session, call delete-image for each image name, and return the outcome of each operation to the client.

Since our plan is to be able to select multiple thumbnails and call the /delete route using Ajax, we need to add some JavaScript to our page. We’ll create a new file under resources/public/js called gallery.js. Our gallery page will load this file, which will provide the client-side functions for managing the gallery.

Let’s write a function to select some images and make the Ajax call. We’ll be using jQuery to help with our JavaScript, so let’s include it in our base layout. This necessitates referencing include-js from hiccup.page in the namespace declaration.

We’re finally ready to write our function to delete the images on the client side.

In that code, we select checked inputs and then grab the ID attribute for each of them. Next we make an HTTP POST and pass those IDs to our delete-images handler on the server.

The server returns a list of update statuses. When the update is successful, the status is set to ok and we delete the corresponding element. Otherwise, we create an error message based on the status and display it to the user.

The JavaScript file needs to be referenced on the page in order to run. We can do this using the include-js the same way we did with jQuery in our layout. Since the JavaScript is specific to the gallery page, we’ll add it directly in the route declaration.

We’ll also require a couple of changes in the way we render our thumbnails, as currently there are no check boxes associated with them for the user to check. Let’s add the necessary references to our gallery namespace and update the thumbnail-link as follows:

Now, if the userid matches the one in the session, we’ll also render a check box along with the name of the image in our thumbnail div (see the following figure).

---

Figure 25. Gallery check box

The check box is there, but we can’t interact with it yet. To do that we’ll update display-gallery to provide a Delete button and a div to display the errors.

Now, if we have a gallery to display we’ll also provide a Delete button when the user is the owner of the gallery. We’ll bind the delete function to the button in our gallery.js when the page loads.

We should now be able to test and see that each thumbnail has a check box when the owner of the gallery views the gallery page. If we select a few images and press the Delete button, they disappear from the page. We can also check that the images and the thumbnails are correctly deleted on disk and in the database.

Ajax and the Servlet Context

The preceding code will work fine when the application runs standalone. However, if we ran our application on an application server, the Ajax request would fail because the full URL would need to have the application context prefixed.

Unfortunately for us, the browser is not aware that our application has a context. One way we can get around this problem is to populate a variable on the page before we serve it.

The request map contains a key with the name :context. The value of this key is exactly what we’re looking for. This might appear to be a bit of a conundrum. After all, we don’t wish to have to pass the request explicitly to all our handlers just so we can grab the context from it.

Luckily, Compojure uses the compojure.response.Renderable protocol to convert what the handler returns into a Ring response. This protocol looks like this:

As you can see, the protocol defines a single method called render. This method accepts the object instance and the request that we’re after.

To use this protocol, we’ll first need to add a reference to it and the ring.util.response/response to our picture-gallery.views.layout namespace declaration:

Since we’re implementing the protocol, we’ll need to set the appropriate response headers manually. To do that we’ll create the utf-8-response function to set the content type to text/html and the encoding to UTF-8.

Next, we’ll create a RenderablePage type that will extend the Renderable protocol. We’ll move the code from our base layout function to the render method.

Since we now have access to the request, we can add a JavaScript variable to the head section of our page with the value of the context.

Lastly, the body of the render method will have to be wrapped in the response function we included earlier. The final result is as follows:

The base layout function will now return an instance of the RenderablePage instead of generating the layout:

Finally, we’ll update our JavaScript to prepend the variable to the URL when making the POST request.

Now the context will be prepended to the URL. When the context is not available, the variable will contain a blank string and the request will work exactly as it did before.