7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

4.6 Rendering Server Views

In this lesson we can use a server view to display the sign-in page to visitors who have not yet authenticated with our application.

4.6 Rendering Server Views

Hi folks, in this lesson, we're gonna see how we can make use of sales, server rendered views, in order to display the sign in page the users will use to authenticate with our application. These differ from the client side views that we might define with something Angular. The main difference is that with server rendered views, the server generates the page before sending it down to the client. Server rendered views reside with the views folder in a sales app. Let's just take a look inside this folder now. We can see that there are a number of files in there already, including a homepage template, which we aren't using anymore, and some error views, and we also have a file in here called layouts. By default, sales uses EJS templates to render server views, and if we open this file up and take a look, we can see that this is where all the common stuff, like doc type, the html tags, the head, and the body tags are contained. Inside the body, we can see that there is a template tag for a body, so this is where the content of any views that are defined or which we add later get injected. So let's add our sign in page as a server rendered EJS template. I've got this file already prepared on my desktop ready to drop into the app. So it's just markup with some Angular bindings, and I've also got an updated version of the styles.scss file and the app.js file, so let's drop these into the appropriate places. Let's get back to Visual Studio. And we can just open some of these up and take a look. So the sign in template has a section with the ng-controller for Angular set to a new signInController. We've got some basic form markup here, and inside the form, we have some error messages and some inputs. And lastly, there's a button that will invoke a method in our Angular controller called validate form. So pretty simple. The styles, I'm not gonna bother showing you the styles. It's just more custom styles in and neat mix-ins for the layout. But let's take a look at the JavaScript. So the new controller is the signInController, most of the logic is contained within this validateForm method. And that just handles the form validation for us, so we can control which error messages get displayed, we've got error messages for the username and password, and also a general sign in error message. And the username and password errors, they are showing if either of the fields are left blank, provided now the fields are left blank, we can go ahead and make a HTTP post to /signin. We added a root for that in the last lesson. And we're gonna pass that user data in JSON format and provided that comes back with a success response, we're gonna then redirect back to slash which is the homepage, and that will show you the dashboard. And if there's a failure, we're just gonna print the failure message and the general sign in error message. And there's also small method down at the end just to take away the error styling when someone starts typing into one of the fields. So again, pretty straightforward. And there's one more thing that we need to do before this will work, we just need to open up the layouts.ejs file once again, and we need to make sure that we have the body set to ng-app. And that just makes sure that the sign in page is able to use the Module and the Angular controllers. Great, so we should be in a position now to test our new sign in page in the browser and make sure that everything is happening as it should. So let's open up a browser. We need to make sure that sales has been lifted, and it was lifted in the previous lesson. I'm just gonna relift that, just to make sure it picks up any changes. So let's visit /signin. /signin, not .signin. And as you can see, our sign in page is rendered. So the reason why it's rendered is because the browser makes a GET request to /signin, and we added a root for GET requests to /signin and told sales to render our sign in EJS file. So let's try clicking the button without entering anything at all. So we see some error styling there, and the username and password required messages. So let's add the username now, and we can see that the error styling goes away. Let's enter the wrong password. And we see our message being displayed that the credentials were not recognized. So that's the message that we added earlier in the course when we configured the passport midway. Great, so now let's try it with the correct username and password. And this time, we do get redirected back to the home page. Fantastic, so in this lesson, we saw how to display a server rendered view to our visitors. Server rendering just means that sales will generate the page on the backend using the EJS layout and sign in files and deliver a complete page back to the client. At that point, Angular takes over in order to handle the interactive aspects of the page. Thanks for watching.

Back to the top