Configure Form and Button For A Post Request

Configure Form and Button For A Post Request

In this tutorial, we will add a button nested inside a form element so that a user can click that button and submit a post request to a specific endpoint on the server. In the last tutorial, all the legwork was completed to set up that endpoint. Now, it’s just a matter of setting up the user interface side with an html form and button element. We will take a look at how to determine what the method and action attribute values of the form should be. In addition, we’ll take just a bit of time testing things out from the browser itself instead of phpunit just to see how things are working.

Edit The Reply Partial

We can open up the reply.blade.php partial view we had already created during this tutorial series. In it, let’s modify the html markup so that it resembles what we have in this code snippet shown below. This should give us a decent looking html button we can use to submit a POST request to trigger the favorite feature.

html button rendered with bootstrap

How To Determine The Form Action Attribute

The method attribute is already set. This determines what type of http verb is used for the request to be sent. The POST http verb has already been selected. We need to fill out that action attribute as well. The action attribute is what determines where the request will be sent to. In our case we want to send that request to this route defined in the routes file.

Therefore, the string contained in the action attribute will be as follows:

Always Include A CSRF Field

The last thing we want to make sure to include in the button and form markup, is a call to the csrf_field() helper function. This will make the form more secure and protect against Cross-Site Request Forgery attacks. The final markup for our partial view with the csrf_field highlighted is shown here:

How To Redirect Back

When an html form submits a request, we don’t want the flow of the page to just stop once it completes. We should perform a redirect for the user, to give a better experience. Laravel provides the convenient back() helper function to allow this. We’ll place a call to that helper function in the controller like so:

Testing The Form Submit Button

In order to create a favorite on a reply, we need to click on the button to submit the post request. Let’s try that now.
auth middleware is working
Right now, the user is redirected right away to the log in page. This is perfect actually, and tells us that the auth middleware we had set up earlier is working perfectly. We don’t want guests of the site to be able to create a favorite. Only authenticated users should be able to complete this task. Now we will log in the user, and try that favorite submission once more.
successful post submit example
Now the user is able to submit the post request to the server and register a favorite. The user is also redirected back right to the same page the post request was submitted from. In the example above, that process happens so fast you almost don’t even realize something just happened. We can check in our database however, and it looks like a new favorite was indeed created in the database. Pretty cool!
new record inserted into the database

How To Display Favorite Count To Users

The user of the site should definitely be able to see the number of favorites assigned to each reply. We will need to modify the view file to display this to the user. In reply.blade.php, we can make a call to the relationships we have defined in our Model to display the count of favorites. We can once again make use of that very useful str_plural() helper function.

When viewing the same page as before, the reply that was clicked does indeed now show as having 1 Favorite. The other reply on the page that we did not click still has 0 Favorites. Pretty cool.
how to display favorite count

A User May Only Submit A Favorite Once

In the prior tutorial, we did a lot of work to set up a test and the supporting code to make sure that a user could only submit a favorite for a reply one time. This was done at both the database level, and the PHP level. With our example logged in user, we can click away like a madman – but you can see the favorite count does not increment. This is very good.
prevent gaming of favorites

Great Bootstrap Disable Use Case

Bootstrap provides a nice class to disable a button in the user interface. Why not use this feature here? It makes perfect sense. If a user has already submitted a favorite for a particular reply, then we can apply the .disabled class to the button. That way the user can not even try to keep clicking multiple times. To do this, we will need to set up a new method we can call to check and see if the reply already has a favorite. Here is how we want the api to work, we can then add the code in the Model to facilitate this.

Now we need to add the method to the Reply Model.

When the user views the page now, we can see that the reply which was already favorited now has a disabled button. The user can not even click that button if he tried. The reply which was not favorited however has a button which is ready to be clicked if the user so desires to apply a favorite to that reply.
bootstrap disabled button example

Configure Form and Button For A Post Request Summary

It looks like we got that form and button working to submit the post request to the endpoint which in fact was our goal. We use a post request, since our goal is to actually modify something on the server. The rules of http dictate this. We also directed the form to point directly at the endpoint we had already configured. Therefore, when we send our post request to that endpoint, a new record in the database should appear. This is exactly what happened so nice work.