Programming Articles

Sometimes you need to upload files to your server from an Angular application to a Web API method. There are many ways to upload a file. In this article, I'm going to present a method that works well for small files, up to about one or two megabytes in size. You're going to build two projects; a .NET Core Web API project and an Angular project. You'll build these two projects from scratch using the Angular CLI, .NET Core, and the Visual Studio Code editor.

In my last two articles (Security in Angular: Part 1 and Security in Angular: Part 2), you created a set of Angular classes to support user authentication and authorization. You also built a .NET Core Web API project to authenticate a user against a SQL Server table. An authorization object was created with individual properties for each item that you wished to secure in your application. In this article, you're going to build an array of claims and eliminate the use of single properties for each item that you wish to secure. Using an array of claims is a much more flexible approach for large applications.

In my last article, Security in Angular: Part 1, you learned to create a set of Angular classes to support user authentication and authorization. You used these classes to log in a user and make menus and buttons visible and invisible. In this article, you'll use a .NET Core Web API project to authenticate a user against a SQL Server table. You'll return an authorization object by reading claim information from a claim table. You'll also secure your Web API methods using the JSON Web Token (JWT) standard.

In most business applications, you're going to want to disable, or make invisible, various features such as menu items, buttons, and other UI items, based on who's logged in and what roles or permissions they have. Angular doesn't have anything built-in to help you with this, so you must create it yourself.

Just like in .NET applications, you might want to have global configuration settings in your Angular applications that you can access from any component or service class. There are many approaches you can take for retrieving these global settings; I'm going to use a service that can be injected into any class. I think the flexibility of using a service is an ideal method for providing application-wide settings to any class that needs them.

Programmers frequently use console.log to record errors or other informational messages in their Angular applications. Although this is fine while debugging your application, it's not a best practice for production applications. As Angular is all about services, it's a better idea to create a logging service that you can call from other services and components. In this logging service, you can still call console.log, but you can also modify the service later to record messages to store them in local storage or a database table via the Web API.

This article builds upon my prior articles entitled From Zero to CRUD in Angular: Part 1 and From Zero to CRUD in Angular: Part 2. If you haven't already read these two articles, please go back and do so because this article adds to the project created in Part 2. In the last article, you learned to add, edit, and delete data via Web API calls. You also learned to handle validation errors coming back from the Entity Framework. In this article, you'll add additional server-side validation to the generated Entity Framework classes. You'll also learn to use the built-in client-side validation in Angular. Finally, you'll create your own custom Angular directive to validate data not supported by the built-in validation.

In this article, you'll add the appropriate HTML, Angular code, and Web API methods to allow the user to add, edit and, delete product data. To the Web API, you'll add POST, PUT, and DELETE methods, as well as a GET method to retrieve a single product. To the Angular product service, you'll add code to call each of these methods in response to user input.

Many business application Web developers build Create, Read, Update, Delete (CRUD) pages in their day-to-day jobs. Over the years, you might have built these pages in Classic ASP, Web Forms, and MVC. You might have even used JavaScript, jQuery and possibly AngularJS. It's now, once again, time to learn how to build a CRUD page using Angular 4. In this series of articles, you'll start with an empty Web application, built using Visual Studio 2015, and build up to a complete CRUD page.

To build a Single-Page Application (SPA) using Angular (v1.x), you typically build a single HTML page and inject HTML fragments within this one page as the user navigates within your application. There are a few different methods you can use to navigate around your SPA in Angular. Navigation in Angular employs a mechanism called routing. In this article, you'll be introduced to many of Angular approaches using the route provider and the route object. You'll learn the various properties of the route object to help you control how routing occurs.

In my last three articles for CODE Magazine, you learned to use AngularJS to search and select data. You also saw how to add, edit, and delete data. In this article, you'll see how to add validation to the page in order to catch any input errors prior to sending the data to the server. Of course, you're not going to get rid of your server-side validation; you still need to protect the data in case someone bypasses your client-side validation.

In my last two articles in CODE Magazine, you learned to use AngularJS, which is a client-side framework, to replace code that you used to write all on the server-side using Web Forms or MVC. Angular is becoming the framework of choice to develop modern Web applications due to its ease-of-use and great industry support. In this article, you're going to learn to use Angular to insert, update, and delete data. You're going to build some Web API calls and connect to those APIs using the Angular data server. Using Angular data binding, the data from your user will be automatically updated in client-side objects, which are then sent to the server via Web API calls.

In my last few articles, I've explored a lot of JavaScript, jQuery, and the Web API. The code I wrote points out some deficiencies when writing in these technologies. That's the problem with JavaScript and jQuery: It's often difficult to write good, reusable, and extensible code. However, things are changing fast in the client-side world, especially now that Angular and other similar frameworks have been invented. In the last article (CODE Magazine May/June 2016), you improved your client-side code by using a closure and by using Mustache for data binding. In this article, you'll learn how these same concepts are applied in Angular.

In the eighteen years that I've been doing Web development, a lot has changed. We started out creating HTML pages to present static information to our users. We then used classic ASP to get database data and incorporate that into our pages. To use both of these technologies, we had to know a lot about HTML, CSS, and JavaScript. Along came .NET and we started rendering everything on the server-side. We forgot a lot about HTML, CSS, and JavaScript as Web Forms wrapped up a lot of that for us. Web Forms' architecture closely mimicked the way developers created desktop applications. This was great for helping developers move to the Web, but unfortunately hid a lot of the power of the Web, and also tended to be a little slow.