Learn how to use Razor Page Models in order to build dynamic web pages with ASP.NET Core.

Razor Pages Syntax II

We learned a lot in the lesson! Now we know the relationship between the page model and our view page and how to attach functionality. Let’s summarize what we’ve learned so far:

- In ASP.NET Razor Pages, a view page (.cshtml file) is attached to a page model (.cs file) by the `@model` directive. Any members defined in the page model class are accessible on the Razor page.


- In ASP.NET, loosely typed data can be passed from a controller/page model to a shared view/Razor page using the `ViewData` property.


- In ASP.NET, a shared layout page can be used by multiple views/Razor pages in order to reduce code duplication. The layout page must use the `@RenderBody()` method to render each view's specific content. Each view can specify a layout by assigning the Layout property. Although not covered in this lesson, layouts can also optionally refer to other sections by calling the `@RenderSection()` method. This method allows you to carve out sections of the page, and then allow the main body of the content to emerge naturally wherever the `@RenderBody()` declaration is placed. For more information on `@RenderSection()`, [refer to its documentation](https://docs.microsoft.com/en-us/aspnet/core/mvc/views/layout#sections).


- In ASP.NET, partials can be used to render HTML output within another markup file’s rendered output. They’re helpful to reduce repetitive code.


- In ASP.NET, Razor pages support Tag Helpers, which are used to add server-side attributes to HTML elements.


For more information regarding Razor Pages reference the [main documentation](https://docs.microsoft.com/en-us/aspnet/core/tutorials/razor-pages/razor-pages-start).

Review


In certain cases, we might end up reusing snippets of HTML, such as forms, on different pages. We can also use these “partials” to break up more complex pages into smaller sections. This is another way to reduce duplication of common markup content across different files and keep our code DRY. ["D.R.Y" (Don't Repeat Yourself),  is a software development principle, the main aim of which is to reduce the repetition of code.](https://www.youtube.com/watch?v=L2cV6VZDGa0&t=48s)

Partial file names also begin with an underscore in their name (through convention). And in order to render the content we can use the following syntax in our content page:

```html
<partial name="_PartialName" />
```

Where `name` refers to the filename of the partial.

Let’s look at an example:

Picture an application with the following folder structure:

```
Razor App
│   Startup.cs
│   Program.cs
│   RazorApp.sln
│   ...
│
└───Pages
│   │   _ViewStart.cshtml
│   │   MyPage.cshtml
│   │   MyPage.cshtml.cs
│   │  ...
│   │
│   └───Shared
│       │   _Layout.cshtml
│       │   _MyPartial.cshtml.
│       │   ...
│   
└───Properties
```

If our partial has the following content:

**_MyPartial.cshtml**:

```html
<div>Here's some content from a partial!</div>
```

We can use the partial in a separate page as follows:

**MyPage.cshtml**:

```html
<div>
  <h1>Welcome to My Page!</h1>
  <partial name="_MyPartial"/>
</div>
```

Similarly to Layouts, Razor Pages will search all registered partial locations for a file with the supplied name and if it finds it, it will render its content resulting in:

```html
<div>
  <h1>Welcome to My Page!</h1>
  <div>Here's some content from a partial!</div>
</div>
```




Using Partials

On top of sharing layouts, we're also provided with a file where we can include directives that will become available globally throughout the rest of our pages. This saves us work in typing and makes maintenance easier.   

There are a number of directives that you'll be able to include in **_ViewImports.cshtml**, three of the most common ones that are added by default are `@namespace`, `@using`, and `@addTagHelpers`. 

- `@namespace`: Namespaces help us organize our code into groups by giving them some context. With namespaces, we're able to avoid any naming collision with other classes of the same name. In this case, the namespace is used to declare the root namespace for your Pages. The default generated **_ViewImports.cshtml** file for most projects will have:
```csharp
@namespace YourProjectName.Pages
``` 
You can only have _one_ `@namespace` directive per **_ViewImports.cshtml** file, the directive is necessary for the models to work. 


- `@using`: Allows us to add imports to all of our Pages instead of having to add them individually per page. For example, if our **_ViewImports.cshtml** file contains:
```csharp
@using Microsoft.Extensions.Localization;
```
then any pages under that folder will have access to members under `Microsoft.Extensions.Localization` namespace without having to explicitly import them with `@using`.


- `@addTagHelper`: This directive is used to give access to Tag Helpers throughout our pages. The default directive includes:
```csharp
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
```
which imports all Tag Helpers to our Pages. We will look more into Tag Helpers later in the lesson.



You might be wondering why not combine both  **_ViewStart.cshtml** file and  **_ViewImports.cshtml** into a single file and share that globally? Well this comes back to the idea of separation of concerns; ViewImports cares about imports, ViewStart cares about logic required for the view pages. Using ViewImports allows us to keep our code more concise and help us create a more scalable application.


Working with ViewImports

   Tag Helpers are very useful ways to create HTML elements with server-side attributes. For example, when we use an anchor tag, `<a>`, we usually have an `href` attribute to direct the user to a specific page when they click it. Razor Pages provides handy Tag Helpers that help us generate links and other useful information.

So instead of writing an anchor tag as so:

```html
<a href="/Attendee?attendeeid=10">View Attendee</a>
```

We can rewrite it with a Tag Helper like this:

```html
<a asp-page="/Attendee"
   asp-route-attendeeid="10">View Attendee</a>
```

 The syntax allows developers to easily customize the UI using HTML/CSS knowledge.

There are many available predefined Tag Helpers to help us generate links, create forms, load assets, etc. There is even one to help us render partials which we just went over! So let’s go ahead and take a look at how some of them work.

```html
<partial name="_ItemPartial" ... />
```

In the tag above, we’re using one of the predefined Tag Helpers provided by ASP.NET: `<partial …>`, the `partial` tag will take a required `name` attribute that searches all registered partial locations for the file with that name, and once the page is loaded, the server will render the HTML from that file. Certain tag helpers have optional attributes that they can take. The partial one has the following optional attributes:

- `for`: Assigns an expression to be evaluated against the current model. This is one way to pass data to the partial.

```html
<partial name="_ItemPartial" for="Item" />
```

Note: The model syntax is inferred so we don’t need to use `@Model.Item`


- `model`: The model the partial references. This is another way to pass data into our partial. The main difference between `model` and `for`, is that `model` allows you to use a more specific model instead of the inferred one that `for` provides. HOWEVER, we can’t use it in conjunction with `for`. We must use one or the other:

```html
<partial name="_ItemPartial" model="Model.Item" />
```

In this case, we could pass in a brand new instance of our model:

```html
<partial name="_ItemPartial" 
model='new Item { Number = 1, Name: "Test Item, Price: 10"}'/>
```

- `view-data`:  Assigns a key/value pair of type ViewDataDictionary that we can pass directly into the partial view:

```html
@{
    ViewData["IsItemReadOnly"] = true;
}

<partial name="_ItemPartial" view-data="ViewData" />
```

During runtime, the Razor Application will process the markup and when it reads out certain Tag Helpers it will convert them into plain HTML before sending the page to the user. For reference, [here is a list of all the tag helpers provided by ASP.NET!](https://docs.microsoft.com/en-us/aspnet/core/mvc/views/tag-helpers/intro#built-in-aspnet-core-tag-helpers)

Working with the Page Model

`ViewData` allows us to pass information from the page model into the view page. `ViewData` is of type `ViewDataDictionary`, which acts as a generic dictionary. What exactly is a dictionary in C#? Well, you can think of a dictionary in the same way as you would think of an English dictionary: a collection of words and their definitions. In a similar fashion, a `Dictionary` in C# is a collection of keys and values, where the key is typically a string and the value is its definition. For more information please refer to the [following documentation](https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2). 

We can add key/value pairs to our `ViewData` in the PageModel as so:

```csharp
public class IndexModel : PageModel
{
  public void OnGet()
  {
    ViewData["MyDogsName"] = "Alfie";
    ViewData["MyDogsAge"] = 7;
  }
}
```

`ViewData` is accessible in the view page and we can refer to the values stored in them by calling the key names:

```html
@page
@model RazorTest.Pages.ExampleModel
<div>
  <p>My dog @ViewData["MyDogsName"] is @ViewData["MyDogsAge"] years old</p>
...
</div>
```

This might look similar to the way you would access properties in the class from the page model, however, `ViewData` becomes very useful when we’re working with layout pages or partials which we’ll cover in the following exercise.


ViewData

Most web apps have a common layout that provides the user with a consistent experience as they navigate from page to page. Certain layouts may include a header, footer, menus, and so on, that may be shared amongst different pages. 

Let’s say we’re building an application that contains a header throughout most (if not all) of your pages. If we’re creating the markup for all these pages, the header will still need to be added to each one. That’s a lot of copy-pasting if the header does not change. We can avoid redundancy by essentially storing the header somewhere separate and rendering its content on each page. If our website needs an update we can simply change a single file and the changes will be reflected everywhere the content has been inserted. 

Standard practice is to specify the location of the main layout page in the **_ViewStart.cshtml** file. This file is automatically generated under **/Pages** when we create a template with ASP.NET and it looks like this:

```
@{
    Layout = "_Layout";
}
```

Here, we’re directing our app to use the **_Layout** file as the main layout for all of our content. But where is **_Layout** coming from? Well, Razor Pages searches by walking up the directory tree from the location of the calling page looking for the filename specified, followed by the **/Pages/Shared** folder. In this case, our generated template has a **_Layout.cshtml** file under **/Pages/Shared**.

Once we specify the location of the layout page, that layout will affect all content pages. You can think of this layout as the main layout that’s used throughout your whole application.

By convention, layout pages use a leading underscore in their filename: **_Layout.cshtml**.

In the generated Razor Pages template the **_Layout.cshtml** file will contain a method call, `@RenderBody()` within the `<body>` tags:

```html
<div class="container">
    <main role="main" class="pb-3">
        @RenderBody()
    </main>
</div>
```

When we work on our own view pages, the content will be rendered wherever `@RenderBody()` is being called on the layout page. 

One other advantage of sharing pages this way is that we can use our handy `ViewData` dictionary and pass data down into our layout page! Let’s say that different pages in our app will have their own title tags. We can create a `ViewData` key/value pair set to title as the property, and unique titles as the values for different pages:

**About.cshtml**

```
@{
    ViewData["Title"] = "About";
}
```

With our key/value pair defined, all we need to do is simply call the property in our Layout page as so:

```
<title>@ViewData["Title"] - Razor App</title>
```

Our Layout will render the value for the title of the page depending on where it’s defined, this allows us to avoid creating unnecessary properties in our PageModel and save us some space!

We don’t always have to use the main layout provided for all of our content. If we want to specify our own layout pages we can do this at the top of our content page. Razor is smart enough to search through a set of predefined locations so we don’t need to provide the whole path of where our layout is located. The filename (`.cshtml` not needed) should suffice: 

```
@{
    Layout = "_NewLayout";
}
```


Sharing Pages

Hello.cshtml.cs connects to Hello.cshtml, which is rendered in a web browser

Now that we have an understanding of how the view page renders C# and HTML, let’s take a look at how we can work with the logic behind it. 

In order to add functionality to the view layer, we must add a `PageModel` class where all the logic will belong. This class is usually found in the **cshtml.cs** file placed in the same folder as the view page. The class file shares the same file name as the view page, albeit with an additional .cs on the end to denote the fact that it's actually a C# class file. So if we have a view page at **Pages/Index.cshtml**, the model page will be available in **Pages/Index.cshtml.cs**.

Our model for the view page will be responsible for exposing methods, commands, and other properties that help maintain the state of the view, and trigger events in the view itself.

Below are some of the advantages that come when separating the logic from the view page:

- Smaller and more reusable units of code allow for flexibility to create scalable apps with more ease. 

- View pages will be easier to maintain if the model needs to be updated or requires changes. If the view page and the model weren't separated, and the model changed frequently, the view would be flooded with update requests leading you to spend extra time fixing and tweaking small changes like method calls or property names.  

- Distinct sections also allow for code to be unit tested &mdash; a practice of creating tests to test the written code, which ultimately allows for automated testing &mdash; a concept that becomes ever more important as a project grows in size and expands functionality.
