Editing Views and Getting Remote and Local Data It's time to start creating the views that are asked to edit the information. So far we've been looking at information and that's nice and we need it, but we also need to be able to retrieve that information and allow to edit, maybe for deletes, inserts or saves. We've put a good pattern in place using the datacontext as our unit of work and then these repositories for our sessions and attendees and speakers. We're going to take advantage of that in this module as we build out the editing screens. In fact, we'll be using this repository pattern throughout the rest of this course, so we'll take some screens that allow us to show data, like a list of sessions, and then show how we can actually open up an editing screen and then save that information, but first, what are we going to cover? Well in this module we're going to show how you can navigate from a list to the details and talk about how you can get the full details as opposed to the partials and this will include the HTML and the directives that we need to use to bind the data from the controllers up to the views. Let's take a look ahead at the next module where we're going to cover building on this to put in the save and the cancel, take an advantage of the repository pattern and Breeze, and also add in change detection and some animations for some visual queues for change tracking. Then after that we're going to cover how you can use cached data for things like lookup lists and dropdowns because when we get to dealing with the sessions that have dropdowns and related data, so in this module we're going to build up the editing for the speakers page and handle all the navigation, the routing, and the passing of the parameters and then loading all the details for that speaker information.
Save, Cancel, Detect Changes, and Messaging Now that we have the editing screen for speakers in place, let's go ahead and enable the saving and cancelling features. Let's go over what we're going to cover. First of all, in the previous module we covered how to navigate from a list of speakers to the speaker details and we took advantage of the routing service and the route params service from Angular and we also made sure we got the full-blown speaker object, not the partial speaker, using our repository pattern. In this module we're going to follow-up on that by adding in the Save feature or the Cancel and we're going to do change tracing and we'll even animate the visual queues for the change tracking and then after that we'll wrap up the editing features by showing how we can use cached data in other ways, such as using dropdown lists and lookups, so let's dive in in this module and show how we can finish up the editing of the speakers.
Dropdowns, Performance via Partials and Cached Lookups We wrapped up editing on the speaker screen, but now we're going to create the session editing screen, and it's going to enable some different scenarios, so it'll allow us to take a closer look at how we can handle cached lookups and dropdowns, and it'll help us take a closer look at the performance of using partials and cached lookups, so let's take inventory in where we've been and we're heading. We already laid out the navigation from out list screens all the way down to getting the full details for editing a speaker. We're going to do the same thing here for the session and then the previous module we handles saving, canceling, and change detection of the speakers. Again, we'll do that for the sessions here, and then the new scenarios we're going to hit are going to be how these things differ for the sessions from the speakers and how we can handle cached data using lookup lists, ng options for the dropdown lists, and enable full editing for the sessions. In this module we'll take some things that we've already learned, apply those to the sessions, and see how they differ as we get into some of the new scenarios.
Saving New Data and the Nullo Pattern Our code camper application is about an event and as such we want to be able to add sessions and speakers, not just edit them. In this module we'll learn how we can add data and save it back to the database using Breeze. We'll have to have a way to get from the sessions screen, where we can add a session, and then route over to the editing screen, which will also serve as a dual purpose for adding new entities or speakers or sessions in this case. We'll take a look at some routing techniques to be able to differentiate between edits and adds and before we can add something to the database, we have to be able to create that entity on the client. We'll see how Breeze makes this really easy for us and we'll also take a look at some techniques where we can manage how we do dropdown selections, so we always have a select a speaker or a select a room, for example, somewhere in our dropdown list, and that'll just help us improve the user experience and make sure we always have related objects in the entity graph, and we'll be using something called the no object pattern to show this. Of course, we'll do this for both sessions and speakers, so now we can edit them and add them both. Well let's dig in.
Deleting and Modal Dialogs We've explored how to insert data and how to edit data and then save those changes or cancel them, but now it's time to take a closer look at how we delete data and also to prompt the user to make sure that they actually intended to delete the data, just to make sure they didn't make a mistake. In this module you'll learn how you can delete data and also, we're going to be using a modal dialogue to prompt the user to confirm that they want to delete the data, and for that we're going to take advantage of some of the bootstrap features and sometimes when you delete data on the client, you have to make sure that anything else that's depending on that data is also synced up, so we'll take a close look at how you can clean up some client-side logic after delete, and some important considerations when you do deletes. To apply these principles, we're going to be showing how to delete sessions from the code camper application because maybe a session was removed from the schedule.
Saving State with Local Storage Sometimes we make mistakes like shutting down the browser or closing the wrong tab in our application, so what's that going to do to our app? Well luckily we have some features like local storage where we can actually save off the state of our application and then rehydrate it when we need to, so in this module we're going to learn how we can take advantage of the local storage features and integrate them with some features available from Breeze in an Angular service.
Storing Work in Progress Sometimes users are on a page and they start editing things and then they realize they want to go somewhere else, but they're not quite finished with their changes, so when they leave the page what happens? Well wouldn't it be nice if we could store up those changes and save those off to a work in progress? Well we have everything we need to do that right now, so in this module we're going to learn how we can save the users progress using a combination of Angular, Breeze, and local storage using the features and the patterns that we've already used throughout this course and this'll allow the user to be able to go off the page and come back, close the browser, save up a bunch of changes for new records, edited records, and then view them in a list so they can come back to those changes and either cancel them or finish them up at a more convenient time.