With the update operations for both categories and

GIFs complete, it's time to move on to deleting entities.

This usually works in an application in one of two ways.

When users are asked to delete something, either one,

they're asked to confirm that they really want to delete.

Or two, a growing trend is that users aren't asked if they're sure.

But rather presented with an option to undo after clicking a delete button.

Both of these approaches require more advanced code than we'll cover, so

we won't offer either option.

But know that a live, functioning application should always have

one of these two options in case something was clicked or tapped by mistake.

Let's start by deleting a category.

Now we're gonna make a decision here that categories can

only be deleted when there are no GIFs present in that category.

That way, we don't wipe away an entire population of GIFs with one measly click.

If we intend on allowing our users the option of deleting a category.

We better make sure our HTML produces the functional ability to do so.

Our category form has a delete button, but a submit currently doesn't do anything.

Let's change this, I'm gonna open the category form.html template.

There it is.

Now if you scroll down to the delete button markup,

you'll notice it's a form in need of some attention.

Right here.

The form's opening tag has nothing in it, no attributes,

no action attribute, no method attribute.

Let's change that.

First, let's make sure that submitting the form will post to the correct URL.

I'll do that by adding a th:action attribute.

And here I'll have timely process the URL by including the at sign and curly braces.

Now this value needs to be /categories/ whatever the category id is /delete.

In order for

our controller method that we have in our controller to capture it correctly.

So I will use Thymeleaf concatenation to make that happen.

So this will be /categories/ whatever

the category id is and then /delete.

And finally, let me add that method attribute here and list it as a post.

One thing to be careful with here.

Remember how we're using this form that is this Thymeleaf template for

both adding a category and editing a category?

Well, when this template is used for adding a category,

that category won't have an id yet, so this right here will cause an error.

Even more, we probably don't even want a delete button to appear when a new

category is being added.

That wouldn't make much sense.

So let's add a th if attribute to check for a null ID and

I will place that right here.

Th if, so here I'll check to see if the categories id is null,

category.id and I'll check to see if it's not equal to null.

If it's not equal to null, then I do want to display this whole div.

So cool, we're all set with our markup.

Next, let's move to the category controller to the method that will capture

this form submission.

So I will open the CategoryController.

And the method we're looking for is the delete category method,

that should be at the bottom.

But we have a couple tasks here to take care of,

first we need to check to see if the category is empty and if so deleted.

In any case, we need to add a flash message and

redirect to the appropriate page.

So first, let's grab the category object using the category services

findById method.

So right here, I'll do that actually above this comment,

I'll call it cat and let's use the category services again.

FindById method and there's the categoryId right there, so

let's use that parameter value categoryId, perfect.

Next, let's make sure to account for

the possibility that the category is not empty.

So I'll say if(cat.getGifs().size() is greater than zero.

So here, if it's greater than zero,

I don't want to allow that category to be deleted.

So what I'll do here is I'll add a flash message

that says something to the effect of only empty categories can be deleted.

So I'll use that redirectAttributes.

And you'll notice here,

I don't have a parameter that is a redirectAttributes parameter.

Let's go add one.

RedirectAttributes, right, now it's there.

So here, to this object I will add a Flash Attribute called

flash and into it, I'll create a new flash message object.

New Flash Message.

And remember we put the text of the message first and then the status.

So only empty categories can be deleted, all right.

And we will use the status of FAILURE on that one.

And if that happens, let's redirect back to that edit form.

So we'll say return String.format and

redirect:/, that'll be categories/

whatever the categorId happens to be, /edit.

We'll get that categoryId from the parameter value here.

CategoryId, cool.

Now if we make it past this if block,

let's use the categoryService to delete that category.

We called it cat.

And we should also add a success message as a flash message.

So we'll do that again, redirectAttributes.addFlashAttribute,

we called it flash.

New FlashMessage and we'll say Category deleted.

And that'll have a status of SUCCESS.

Add my semicolon there, wonderful.

And now let's redirect the browser back to the /URI instead of returning null here.

So I'll redirect to /categories.

Now let's check our service and

Dao implementations to see what is left to code.

So let me open categoryServiceImpl.

CategoryServiceImpl, now it looks like our delete method isn't finished yet,

so let's call upon the Dao to do its work here.

So we have an override categoryDao.

So let's grab that and

call it delete method, passing the object we receive as a parameter value.

Now before we head to the categorDaoImp,

one word about this service implementation.

Back in the controller we check for non-empty categories.

There's plenty of reason to do this in the service layer instead of the controller

like we did.

And I encourage you to experiment with this.

For example, you might check for non-empty categories here in this method.

And if you find one, throw a category not empty exception,

which would be a short class that you would write.

Then, in your controller,

you could surround your service call with a try catch.

With this set up, you wouldn't have to duplicate the check for

non-empty categories if you want to reuse this service to power say an API as well.

Check the teachers notes for more information on that approach.

Okay, let's switch now to the Dao implementation.

So in the dao package, I will open CategoryDaoImpl and

let's focus on this delete method here.

In here we'll stick our normal transactional code.

That is we'll open the hibernate session.

We'll begin a transaction, we'll delete the category.

We'll commit the transactions, so session.getTransaction().commit().

And then we'll close the session.

Okay, with code written all the way from the UI to the persistence or

dao layer, it's time to test this feature.

Let's restart the app, I'm gonna open my panel here.

I'm gonna kill the previous instance of this application and

rerun that bootRun task.

Looks like everything compiled successfully and

let's see if we start successfully.

Cool, let's switch to Chrome now.

Now when Chrome, I want to navigate to a category without any GIFs and

click delete.

So I'm gonna go to categories and let's go to Validation,

I don't think I have any GIFs in here.

And I'm going to click Delete.

Now, low and behold, we get an error.

Now check out this message here, it says,

failed to lazily initialize a collection of GIFs.

Keep that message in mind and

let's flip back to IntelliJ to see if we can see what happened.

In IntelliJ, if I scroll up to the point in my console

to where the exception was first displayed.

I find that the culprit in my source code

is located in the CategoryController on line 130.

I'm going to click on that and

this is the line that is acting as the culprit in this case.

Now what that error message was saying is that a collection

in this category entity right here was not initialized.

What collection is that?

Well, it looks like this collection right here, let me show you what's happening.

I'm gonna open the Category entity.

In this Category class, we have a mapped collection named gifs.

Now, this collection by default is configured to

not be initialized when a Category entity is fetched from the database.

This is called lazy loading.

It turns out that in this OneToMany annotation here,

there is another element that you can specify here called fetch.

Now the default value of the fetch element is indeed fetchtype.lazy.

Now you can change this to fetchtype.eager,

which means that every time one or more categories are fetched from the database.

Another query will be performed to fetch all GIF

entities from the database that are associated with that category.

Now, a word of caution one eager fetching.

If Gif lib has many categories and each category has many Gifs,

then getting a list of all categories would involve executing more queries.

To fetch all the Gifs associated with every category,

which we aren't even using in the category index page.

This would be a huge waste of resources and

would make our users wait a long time for request to process.

Fortunately, there's a better option for

our scenario, we can simply initialize the collection when we need to.

Let's go back to the CategoryController to remind ourselves

of where this Category entity came from to begin with.

So in the CategoryController, we got this category object

from a service call to the findbyId method.

The way our application is coded right now, it makes enough sense to fetch

all the GIFs for a category, only when a single category is being fetched.

So all the way down in our Dao layer, we can tweak the findById method as follows.

Let me go to the CategoryDaoImpl.

If I scroll to the findById method, here is where we'll need to make those changes.

Before I close the session,

I'm going to call Hibernate.initialize on that collection of GIFs.

Category.getGifs.

What this will do is it will make sure that that Gifs collection

is initialized before this session is closed.

We were seeing that error because we tried to access a mapped collection

outside of a hibernate session, which just isn't possible.

So with that in place, let's test this again.

I'm going to kill this app and I'm going to rerun that bootRun task.

And it looks like our applications started successfully, so

let's go back to the browser.

I am just going to hit the back button to go back to that edit form and

hit Delete and see what happens this time.

Hey, look at that category was indeed deleted.

Now if you recall the name in that category was Validation and

I no longer see that category here.

And in addition,

I see this nice flash message indicating that the delete successfully worked.

Now of course, we'd wanna test this with the non-empty category as well, so

let's find one to do that.

I believe we had one in Technology, so let's delete that one.

And there we have it,

that flash message indicating that only empty categories can be deleted.

So that Technology category is still here if I go back to the list of categories,

we have not lost that Technology category.

And we have successfully prevented the deletion of categories that contain Gifs.

And there you go, deleting categories, done.

It's time for us to move onto deleting the Gifs themselves, prepare for

another coding task.