Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
FREELessons:16Length:2.1 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.8 Viewing Tickets

In the previous lesson, we started writing the code for displaying a ticket. And currently, we would display the ticket after we submit that ticket. And now we just need to write the back-end code so that, first of all, whenever we submit the tickets, we will get the newly created ticket's slug. And then we can use that to not only navigate to the view page, but also use that inside of the view page to get all of the ticket information again. So let's start with our SubmitTicketFormComponent. And we want to change this back to how it was. We want to validate the form and then we only want to navigate to our viewing component if the request is successful. So this is going to go inside the then method. And we should also add the catch method as well, so that we can catch any errors. And let's just, for the sake of laziness, just alert the error. Now we need to get the ticket ID, and that is given to us through this response object. We have a data property and then ticketID, and that is how we will supply that. And that's great, so we should be able to just go to the controller now and return that value, inside of the store method. So let's go to that store method. And then all we are going to do here is return the ticketID. And this is one of the things about a restful API. In some cases, you want to return as much information as possible. But in other cases, you really only want to return just a few pieces of information. You want to limit the surface area of the data that you return, and this is for safety precautions. Because you don't want to leak any extra information that you don't want to. So that's what I'm doing here. There's really no need to return anything else. Of course, in this case it's rather mundane information. But if we had a password field or something, we would definitely not want to return that. So in this case, we are limiting the surface area of our API so that we are working with only the data that we need. And that is the ticketId here. So that whenever we submit a ticket, let's refresh so that we have everything loaded. And we should get to ticketID and it should navigate us to our view component. So as far as the title, this is the title and who cares what the description is? Let's submit the ticket, and here we have our ID. And in hindsight, that’s a little long, I will admit that. However, it is sufficiently unique, at least I would think it would be. Because not only are we getting a unique ID but we are also creating an MD5 hash of that, so yeah, that should be unique. Let's do this, let's change this to an h2 element, so that it's going to fit all on one line on screen. So let's refresh, and there we go. So now whenever we come to this component, we want to take the ID that was given to us. And we want to use that in another request to retrieve all the ticket information. Now you might think that that's rather redundant. Yes, we just made a request, and we actually got data back. However, if we are going to use this URL for actually providing it to a user so that they can navigate straight to this page, then we need to make that request. And while we could add the logic to make the request if we don't have the data and all that, let's just simplify it. Let's just make the request. It's not going to be that big of a deal. We aren't returning a huge HTML document. We are just returning a small little JSON structure. So let's start by displaying the information that we want to display. So the email address is something that we would probably want to display. However, you could make the argument that the person viewing the ticket knows what their email address is. But we will still display that, and we definitely want to note the status. Because as a user, I would want to know where in the process my ticket is. So we will have the status. And at some point, we need to decide how we are going to do the status. Do we want to return the numeric value to the client and then let the client decide how it's going to display that? Or do we just return the actual status from the server, pending or completed? So we'll cross that bridge when we get there. Now when it comes to the content, let's do this. Let's have an h4 and we'll say Content. And then we will display the content by itself, so that it's not going to interfere with any other type of data. And when the technician adds notes, we would want to display the notes here as well. And we might even want to display the technician, but we don't have any of that yet. So there's no sense in trying to implement that. But I think that that's okay here. The email, the status, the content, and that's it. So let's go down to our JavaScript code. And let's, first of all, import axios because we are going to need to make a request. And let's make the request inside of our mounted event, so let's say mounted. And then we will make our request. Now this is going to be a get request. And let's use the new string interpolation features. And our URL is going to be api/tickets and then we are going to incorporate our ticket D there, and that will be our URL. And whenever we get a response, hopefully it will be a good response, then we will do something with that data. Otherwise, if we have an error, let's catch it. And we won't do anything really useful. We'll just alert the error. And eventually in a real world application, we would want to come in here and provide some meaningful stuff. But we'll just leave that for right now. And as far as this do something is concerned, we want to populate our email status and content. So we need that as data, first of all. So let's return our object that is going to have an email property. We will initialize, pretty much everything, as an empty string. Although, as far as status is concerned, yeah, let's do that as an empty string, as well, and content will be an empty string. So there we have that. And then inside of our little callback here, we will say email =, and then we would use our res.data and then email. And we would essentially just do everything else. Although as far as the status is concerned, now we need to decide how we are going to do that. Do we want to determine the string here in the client, and I guess we could since we're here. So if status = 1, then it is Pending. Otherwise, it is Completed, because that is how we had this set up. And that should be okay. I don't think there's any other pieces of information that we need here. So let's actually write the code that's going to get that on the server. So that's going to be our show method. Now, we will have access for the show method. Even though we set up our routes using the API resource method, the show method would normally return a view. But it's also used for returning an individual ticket, in this case. So here we want to retrieve our ticket with the given slug. Even though this says id, it is not our id. This is the slug. So,we can't say Ticket findOrFail but we can say where the slug is going to be equal to the provided value. And then we could say firstOrFail and then we want to return the pieces of information that we want. Once again, we want to limit our surface area here. We don't really need the dates and, in this case, we don't want to return the actual ID. Even though the slug is a unique value, we are going to kind of obfuscate that as well because we are calling it a ticketId. So if there was any attacker that wanted to try to do anything based upon a ticketID, they don't even have the correct name for our field in the database, so that's a kinda nice little thing. So in this case, our ticketID, even though we should already have that in the client, it's kinda nice to go ahead and return that here as well. Even though we had to know it to make the request. So we will just return that. We'll do the same thing for the email, and I'm still in JavaScript mode here, so please forgive any typos. We'll have ticket, email. The content is going to be from our content property. And then since, we aren't doing anything with the status except just returning the status value, that's what we will do. So there we have the four pieces of information that we were returning. So whenever we refresh the page here, everything should be fine I would think. The email is not what I would think it would be. That is definitely not an email address. The status is pending, that's great. The content, well, the content is the same as the email address, so apparently I have screwed something up somewhere. And let's look at the store method. Title, title, email, content. There's the problem, right there. So that means that every ticket that we've created has [LAUGH] not the correct email address. That's okay. That's what development is for, so that we can find bugs and fix them. All right, so we now have the ability to display the ticket information, and that's wonderful. So that starting in the next lesson, we can probably start focusing on the admin section. That's where the real fun comes into play because we get to edit everything. And we also get to incorporate user authentication.

Back to the top