If you've been along for the ride so far with this series, you already know that we've hooked a SQL database up to RIA Services using an ADO.Net Entity Data Model and a DomainDataService data context. If you've missed it, check out the prior two posts (or search RadScheduler for Silverlight learning series in the Telerik Blogs site). Now that we're here, we have three more events to handle and we've got a fully-functional RadScheduler for Silverlight hooked up to RIA services.
First up, the two easy events- AppointmentAdded and AppointmentDeleted.
This event is pretty straightforward and does not require very much explanation. When it fires, RadScheduler has already created an appointment internally that comes to us in the argument e.Appointment. Once we have this, we simply turn the appointment into an SqlAppointment (which our data context understands), generate a recurrence string from the recurrence pattern of the appointment (don't gotta worry about exceptions because a new appointment won't have exceptions), and add it to our data context. You can do this as follows:
Again, it is pretty wasy to figure out what is happening on this one. RadScheduler has already deleted the appointment internally, so all we need to do is to let the context know which appointment we are deleting. Since all recurrence exception info is stored in our appointments we don't need any complex operations, so this next part is pretty self-explanatory:
Now we get to the fun stuff. :)
When editing an appointment, there is one big question that needs to be asked- does this in any way, shape, or form involve either Recurrence or Recurrence Exceptions? If the answer is no, then editing an appointment is pretty easy as it looks a lot like creating one. That would involve grabbing the appointment from the context via the UniqueID of the appointment we edited, making our changes, and doing the all-too-familiar context.SubmitChanges() operation.
But what if there is an ExceptionOccurrence? Then we need to check it by one of four states:
Looking at the examples from the links I provided in part 1, you can see these can be somewhat of complex operations when you have related tables. But since I wanted this at some point to be cloud-ready, storing serialized exceptions in a field of our appointment allows us to use RecurrenceExceptionHelper to come to the rescue. When adding, deleting, or editing an exception, since we are in the Edited event, the new Exceptions list is already updated, so all we need to do is serialize that and set it to the ExceptionAppointments string. If ExceptionAction.None, we've changed the recurrence rule, which wipes exceptions, so all we need to do is reset that string. Here is the full Edited event:
In a future iteration I'm going to refactor out the conversion from Appointment to SqlAppointment, so this will be even shorter in a later installment.
And there you have it! But since I've teased enough with this, you can download the full project I've been working with from here:
In the next installment I'll give a brief overview of this magic RecurrenceExceptionHelper class that makes saving and editing appointments easy as pie. Beyond that, we're going to explore customizing our appointment editing window, modifying appointment appearance based on different resources in the appointment, and showing you just how to take advantage of the Location, URL, Developer, and ProductLine fields in our database.
'Til next time... happy coding!
Evan Hutnick works as a Developer Evangelist for Telerik specializing in Silverlight and WPF in addition to being a Microsoft MVP for Silverlight. After years as a development enthusiast in .Net technologies, he has been able to excel in XAML development helping to provide samples and expertise in these cutting edge technologies. You can find him on Twitter @EvanHutnick.
Subscribe to be the first to get our expert-written articles and tutorials for developers!