In this lesson we're going to take a look at expression language. Now, expression language can be very big, their entire volumes written on it. But we're going to try to hit some of the key points and really get you comfortable with it quickly. So we're going to describe the purpose and benefits of expression language when you would use it. Why you would use it. That tends to be pretty obvious with this one. Most developers see it and go, thank you very much, I'll take that. We want to learn some of the foundational rules used by expression language. We want to understand the difference between dot and bracket syntax. A lot of people code for literally years without knowing the difference between these two are understanding the smart way to use them. And then we'll get comfortable with some of the most commonly used implicit objects and expression language. So what we'll find with expression languages that makes things a lot easier to read and understand, and most developers fall in love with it pretty quickly. So take a look at where they are used, being that we know pretty well. This was great when it came out, but it evolved into this very nice thing in expression language that we can access much quicker and much easier. So it's kind of like which would you rather type the upper set of code? Here are the lower set, and you can see why expression language was a big hit with developers right away. It's very precise, very easy to understand and just notice that there's a dollar sign and then curly braces. And then it's really just kind of dot notation inside of there. Same exact code. These are equivalent. Let's take a look at some rules we've already said is demarcated by the dollar sign and two curly braces. And by the way, you'll even use it on some spring projects. And you'll use something similar called spring expression language that borrows heavily from the concepts here. So some examples of use you can see, and then I actually like to see code. So I think it's easier to understand. But you can kind of see the different things you can do with expression language here. And then again, your example, request scope dot item dot item name. Hey, that's pretty easy. I want to go into my request. I want to find the bean with the name item, and I want to get its item named property. Do note that in this template here, you can use some map with a bracket or some map with the dot notation, and the bracket is preferred. It's more efficient and more precise, and we'll talk about that a little bit later as well. Alright, so we have two ways that we can access things. All right, so we have two ways we can access things. The first is with a dot operator, and the second is with brackets and most of use Java developers just jump right into the dot operator and love it. And there's a good reason for that. But you'll learn that there are a few things that are even better about the bracket operator. If I'm using the dot operator, the thing on the left can be a job of being or a map. That's it. Those are my choices. Those are the only things that can be, and the things on the right can be a being property or a map key. When you're using dot notation, you're kind of limited to Java being or map and a property or a key. When I'm using the bracket operator, I can actually do list so it can be a job of being or a map as before. But it can also be in a list or an array, which is very handy. And the thing on the right can be a bean property, a map key, a string or an index of a list or array. This is really nice and a bit more powerful for processing collections and things of that nature. We will touch on operators briefly, but they're pretty much what you're used to Already. Arithmetic hasn't changed since your early high school days, and the logical and and yours are the same as they are in Java. We have the short circuit, and then all of our relational operators are available to us as needed. So there is a nice prefix to see whether a value is null or empty, and this can be very handy in a presentation layer every once in a while, so do keep that one in mind as well. And then we have implicit objects, and the good news is you already almost know these are very straightforward, and I think you'll find them very quick to learn and pretty self descriptive. So you have everything from program to cookie two page scope, request scope session scope. These are the ways we get at them within expression language. So when you have that dollar sign, these are the variables, the implicit objects you need to use inside of there. The other thing to note here is that everything here is a map except for page contact that comes in handy as well to help you learn if you understand that each one of these is a map behind the scenes. So let's take a look at some examples inside my HTML form. No surprise. I have a form with an action of add items jsp. I have a method of post. I have a couple of input types. I'm looking at item name and item price, and then I submit well inside the jsp that I'm calling the add items jsp. I can say request program item is and switch to expression, language and used by implicit program and then just ask for the property name. So that's pretty nice. I'm asking for the program name here and the program name here, the two that got sent over from my request. The good news is that expression language will usually convert your types as needed. So in the example above the item price, that was a string, and we needed it to be a double. It'll get converted as it comes and goes very nicely, and you'll see that's the case for almost all of the expression language. But occasionally you do have to deal with one on your own. You need to understand some scope rules. This will save you a bit of headache and is the source of a lot of bugs for new jsp developers. And the way to understand this is to take a look at this item. Price is item dot item price and understand when it's written just like this. What this expression language will do will start searching these scopes in this order. So it'll first looking page scope and say, do I have an item being or object that you're asking for? Then if it's not there, it'll go to request and session and so on. If I only want to look in session, I can qualify it by saying session scope dot item dot item price. So which is better? Well, there's not a huge performance thing, but there's a little bit of a performance when it has to search through all of the different scopes. But moreover, where we really see bugs is if you just get busy or another. Developers working with you and one of you put a bean inside of request named item and another one puts it inside of session named item, and you're both trying to do it. But this time you need the one from session. But it grabs the one from request first, and you're not getting the answers you expect or the data you expect, and it can be really frustrating to do so. Our recommendation is just qualify the scope when you need it.
