So we have a nicety that we'd like to add to our API.

We want the creator of the review resource to be set

as the reviewer when it's created.

This idea of running certain code at certain times is pretty common request.

As you can imagine it's usually where the business logic lives and

since all the controller code is currently tucked away out of sight,

it might be a little confusing as to where we should add logic like this.

Well the good news is that this problem has been thought about and

it has been solved for you.

Probably, there are eight events that the spring data rest emits.

These are pretty self-explanatory and

knowing what you can hook into that will probably make you feel a lot more

comfortable about not having access to those controllers.

This is usually where you'd write any custom logic, right?

So we want to set the reviewer before things are created.

So we'll use the before create event.

Let's do this.

There are a few ways to register events.

If you wanna capture all entity creation you can write an application listener.

But in our example we're really only concerned with when reviews are created.

What we're going to do is write an annotated handler.

Which we can restrict to a review entity specifically.

So in our review package, let's make a new class named ReviewEventHandler.

New Java class ReviewEventHandler.

Okay and now we'll annotate that with RepositoryEventHandler.

And with that does is that takes a class and

it's whatever we're interested in watching which remember that's Review.class.

So the way that these work is you define what it is that you're

trying to do in a descriptive method, right.

So let's go ahead and let's say.

We're trying to do is we're trying to add the reviewer as it goes, right.

So let's say public void addReviewerBasedOnLoggedInUser.

It can be as descriptive as you want.

So we'll say review review and we want this to happen before, right?

So we're going to do handle before create.

So having these as separate methods is pretty nice because each of them are right

for unit testing right.

Okay so let's inject our user repository so we can get stuff out of it, so

we'll say private final UserRepository,

so users, and I'm gonna go ahead and allow this.

With this automatically add a constructor parameter and

then we'll mark our constructor here as auto wired.

And because we need to have this picked up by a component scan,

we need to mark it as a component.

And now let's work our magic.

So, to get the currently long in user you do this incantation.

So let's say get user name and that's from security ContextHolder

has a getContext, I'll go ahead and give us some space.

Has a getContext, and then it has a getAuthentication,

and then it has a getName.

Note that we're going to get a null pointer exception here if they aren't

authenticated.

But alas, they should be so we'll go grab our user.

So we'll say user user = users.findByUserName and

we'll pass in that username.

And finally, we'll just set it on the reviewer and

the review will say setReviewer[user] makes sense right?

Before things are created, okay?

I will go and reboot our server here.

Let's see, let's grab somebody over here to make a review for,

let's see, let's grab Seth Kroger.

He is an amazing moderator for us so let's write an appropriate one for him.

So we're going to make this a post and we're going to erase this one and

we're gonna go to the authorization we're gonna log in actually as Seth,

he's got the same password which is password.

Seth change that, say update request, okay.

And if we come over here to the body, this is actually a review.

So what we wanna do is we're gonna have him give us

a little bit of a harsh rating.

Let's say the rating.

Let's do the course first.

So "course" and now again we've moved this.

So it's "/api/v1 Courses one so

basics and we're going to give a rating of two.

That's pretty harsh stuff, which what, what's he upset about?

What is Seth upset about?

Let's see.

So for the description come here and

say why why did you use

system.io.console.

Well that's a lot isolation points so I have to calm down.

Do you know how many times I've had to answer

why this doesn't work in the clip.

I totally made that up, that's something Seth would never ever say.

He's one of those amazing moderators that makes everyone feel so

comfortable in the community and thanks for keeping something so positive and

being so patient that the students and I really appreciate it.

Okay let's see if this works.

So we have not set the reviewer, but Seth is logged in, and

we're going to click send.

Here we go. We got a bad request because,

why did we get bad request?

No suitable found to read the request body to object.

Do I have a weird header?

I did not set this.

I said it as text that something good to know, right.

So doesn't know it says and it says right here.

Can't do with the content type plaintext, right?

Let's switch this over to my application JSON and they set there.

Maybe that will be an answer for this one isn't better there in the video.

So that's maybe one you don't have to answer.

Boom, there it is and here comes Seth Kroger coming across.

So as you can imagine, we could do all sorts of other handling in these events,

including sending notifications, updating caches, some advance validation.

But whatever business logic you can dream up you can put in there.

Now one thing to always remember here though is that this action is synchronous

meaning that it's in the request response loop so users will be waiting for

this code here to execute.

So don't do anything too intense In here.

Awesome, right?

I know when I was first looking at the spring data rest project

I was not very trusting.

I was like, yeah sure I guess we do duplicate

a lot of code when we write APIs.

But where's all the business logic code?

Events are where you can inject that.

I've also found that these methods make unit testing your business logic

simple and quick.

Speaking of testing, it's outside the scope of this workshop.

But I do beg you to remember that you don't need to test what has

already been tested by framework creator.

Remember your boundaries.

Test only what is your responsibility and what could actually break.

I suggest you test your validation, your security, and

that your custom events are working as you intended.

But please don't go and test status codes and

error message that you haven't customized.

Find the right balance, and remember to not test what has been so

graciously abstracted away for you.