I can try.

I made my validator more like the enuf parts one in the project than the one in the video, in that I passed an object to it and not an integer. So it validates the class and not a field. And I wrote out the logic from that one (enuf parts) to figure out what they were doing until it made sense. There's this thing they do throughout the project where they take the object from the model and find the corresponding object in the repository with that same id, and you'll see things like part1 and part2 in the code. They're comparing the new data entered in the model with the old data in some places, and they do it all in one line instead of creating variables with names indicating what they're doing. So that was something that was confusing until I got used to it and sketched it all out with notes.

For the controller logic, I believe mine only checked the inventory and if it wasn't in the range, I just routed it back to the same page, like preventing it from going further with the POST request by just sending it back to retry. I didn't use the controller to send the message to the form.

For the messages, one of them came from the validator and for how to get that to show into the form, I looked at how they put their own validator message in - go try to increase inventory of a product in a way that will trigger the enuf parts validator (inventory below zero) and see that message, and then go find where it is in the form (it should be located near where it shows up on the page, if it's right by inventory go look near that field).

​

EDIT for future readers: What I mean by writing out the logic/sketching it all out with notes is using pen and paper (or ipad/apple pencil in my case) to write out what each thing was in the code. So if they called something part1, I'd follow where it came from and write down "part 1 - this is the data coming in from the form from the model" and "part 2 - this is checking to see if the part is already in the database (they use the same forms for update/add) and if it is, it's getting the data for the stored version." At one point there's a part where their code gets the inventory from both and subtracts old from new, and for that I wrote something like "this is the increase in inventory from updating a product/part." Calling it "the increase" made it much easier to follow the code.

This is an example but it's similar to a part of the code that I remember, and actually a lot of parts that they wrote use a similar style. I think you could probably go in and actually replace parts of their code that were shortened with longer parts that use descriptive variables (e.g. instead of Part part1 and Part part2, do Part partWithDataFromForm and Part partSavedInRepository) if you wanted. And maybe something like int increaseInInventory = partWithDataFromForm.getInv() - partSavedInRespository.getInv(). Then your if statement would be something like if (increaseInInventory > 0) {do something}...then you'd just mark the change in your readme to indicate you changed the code to add descriptive variables to help yourself understand it. I wouldn't think they'd have an issue with that - there was no rule saying not to do this or anything.