Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Phalcon 3
  • Overview
  • Transcript

3.4 Updating Contacts

In this lesson, we'll work on the remaining major bit of functionality: the Edit Contact form. This is similar to the Add New Contact functionality, but there are lots of new things to learn along the way!

3.4 Updating Contacts

Hi everybody, welcome back. So, in this lesson, we will work on the remaining feature, the Added Contact Functionality, which supposedly should be similar to Add New Contact, but that's not the case. For this, we will have to apply everything that we have learned from previous actions so far and almost similar amount of new things of its own that we will learn along the way in this lesson. But the basic idea is quite similar. It will have two actions, one for the rendering of the form and other for editing the contact in the database. But an interesting twist here will be, prepopulating the form fields with the use like this. The interesting thing is the usage of ID passed in the URL, since the form will submit the data that post request, but since we have to update a particular row in the database with new values, it needs the ID passing the URL. I'm sure it's going to be quite an interesting roller coaster ride for you, so let's quickly jump into it. The code itself is divided into three major parts like the previous lesson. First, one for the edit action, next one for the view, and lastly the actual update action. Then each part is further divided into the subparts of their own, too. Starting with the part one or the phase one where we are implementing this edit action, that takes us to our view. The edit action has two simple steps like a delete action in step one. First, we check the request with if condition to see if it's not an invalid request, and then get the ID from the URL passed in the parameter and fetch the records from the database using it. We can do it by using find first method like we did in the delete action. Once we have the results, in this step two, we need to send the values to the view. For that, first check if we have any values in the resulting variable in the first place. If not, then a nice little error message, something like don't try to be smart and added an invalid contact would be great. But, if we do have values, then we can pass the values by using a method from tag services called displayTo, which can set the default values to HTML tags that you are going to generate in the view. It takes the name of the field and the value you need to assign to the field. Last but not least is this S block, which will be executed in case of an invalid requests. So, let's flesh a nicer message here as well, great. The only other thing this step two need is very directions, but in this case, three directions are a bit trickier than the previous ones. Here I can see three different situations where the code cannot stop its execution One is the else block with Invalid Request!!!. Another is with invalid contact. Both of them must take us back to the index page, but since both of them are in separate code blocks they will need a separate dispatcher, but with a similar target. Then there is this third block of code, which needs to render the edit view with pre-populated values in the form. So if we don't interrupt its execution, it should seek for the default edit view file. And render it. And that's what we want with this is step two finishes and so does the part one of this lesson. In the second part, we are going to prepare the view by first creating a new view file with the same name as the action, followed by copying everything from the view with the form and then pasting it back here in the edit view. Since both of the views are quite similar ones copied first, we can start by modifying the title here and then followed by the action URL, which now should be updated. Which we will define in the third part of this lesson. Then don't forget the name of the submit button And lastly one extra field, but a hidden one for keeping the ID. The hidden field will not be visible in the browser but once the form is submitted it will also be submitted to the update action like the other fields and that's how we are passing the ID to the update action. The reason we need an ID to be passed to update action is because we don't want to update all the rows in the table. We want to get a selected row updated with the new values. And that's about it from the part two. Now that we have everything in place. Let's jump into the browser and try to edit any of the rows. There we go a nice clean form with all the values prepopulated for us. Good! Now with an invalid I.D., perfect error message on our next page. If we will try to use this update, but it will display some errors. So let's quickly jump into the controller for the third and last part of the lesson and create a new action. I'm going to name it. Of that action. Part three is divided into folder steps almost similar to the earlier ones. Let's quickly start with the step one. Where will we check if the request is invalid? This way this action will not be accessible by trying to access it with the URL from the browser. It's only accessible to the form Or the tools that can generate a post request. In step two we would like to first flash the record from the database like we did in the delete and edit direction but just with the small change that this id variable here needs to be defined and assigned a value from the getPost and then do the validation. And enter a message in case there were no such records found in the database then comes to step three and four there where we will update the first record which is very similar to the create action. Just by using the same Save method but with new values received by the form this time And that's it. It should do the trick. Lastly we just need to check if the operation was successful and then change the messages accordingly. In the step for the last thing that remains is the redirections. There is a tricky part waiting for you in this one too. Let's give it a look. In case it's an invalid request, we wanted to send us back to an index page So it's good, in case we didn't find the record, it must go back to then, this page as well. So this one is also good. Now in case of success and failure of update operation, success is quite a straightforward. Going back to index page with the success message should do, but in case of failure along with forwarding it to the edge detection, we also have to provide the ID. As a detection doesn't throw any error messages and pre populate the values as well. So for that we will pass an area in the forward method which will contain the name of the targeted action and then the params which takes another area by the way just with one element ID that can be taken from the request object like we did in the first step to find the record from the database and with this are a step for finishes as well. The code seems to be ready. Though I have some extra tips for you under direction, but let's test a feature first. So jump into their browser. Tried to update any of the record. Let's update the phone number may be. Great. So it works as expected The values are successfully updated. Let's try to see how the validation work. So, remove the name and tried to submit it. There you go. We are sent back to the same page with an error message, and the name is back as well. Very good, and other case can be trying with an invalid ID. And, it should send us back to the index page. With an error message. Great so far so good. Now the one last night or that we must try to test is to access the update action from the browser with the URL. And there you have it or it was an invalid request. So everything works quite well and we are basically done with the lesson. But before we do that there is one last thing, if we go back to update action and look at the code You see there are three separate cases where we want our action to go back to index page, but with different less messages of course. So let's say, if we want to refactorate and try to remove the duplications. One approach can be just removing the dispatcher to the index action from every viewer, And then keep it just outside of all the if else blocks like a common dispatcher for up detection. But this approach can create one issue in case of addition fails. Let's try to test it. If we tried to update a record with no name. It must throw errors and should keep us on the same edit page. But now it doesn't do it. It took us to the index page this is because of an address better is fired. It sure executes the targeted action but doesn't mean it takes a question of current action. Hence after this to spread or is fired the control goes to the next line and due to the last dispatcher index we lose the one that we see on this screen so to fix this issue we can use returned with dispatch or which. Which was turning at the execution there and moved to the forward direction. Let's try it again. Go to edit, remove the name from the form and submit it with an empty name. You see the different? This is also going to be useful in situations where you want a more readable code. Like there are two different styles of using if statement. One that I have used here mostly using IF and then ELSE statements. But if there are too many nested IF and ELSE blocks, it gets harder to read and understand the code so some of the developers prefer the IF and RETURN style like here in this. If an else you could also check if the success is false and do the required task. And lastly, by using return you can terminated. Else, this block will never be executed which eventually means that it was a success. Hence the flesh of the success message will execute You can quickly jump to the browser and test it should work as it used to do before. So these are a couple of cases where we might need to use return depending on situations, and as per your business logic when you will have to write more complicated code taking care of every situation where you have to call the dispatcher again and start to be very tricky So unlike this course, if you will keep writing this better along with logic, it can save a lot of debugging time for you. Finding the cases of your displeasure is needed in the end of each action was just to make you understand the concept better. But it's not a preferred practice. So with this we have finally reached to the end of this lesson. And almost to the end of this chapter. We have finished our phone book application. It sure is not a full fledged fancy context app like Google's. But I think it's quite good enough for us to break the ice with Falcon and Get started. In the last lecture I have planned a little bit of code cleaning refactoring along with some tips and final touches for you guys. We will also learn how to create and use the configuration files in Falcon. This will help you keep the ever growing bootstrap profile much clean and easy to understand. So I will see you guys in the next one till then bye bye.

Back to the top