RadScheduler for Silverlight learning series, part 3: Add, Edit, and Delete Appointments

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.

AppointmentAdded Event

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:

AppointmentDeleted Event

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:

AppointmentEdited Event

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:

• ExceptionAction.Add - We add an exception to a recurring appointment
• ExceptionAction.Delete - We remove an exception from a recurring appointment
• ExceptionAction.Edit - We edit an exception that already exists
• ExceptionAction.None - We've reset the recurrence rule so exceptions need to go the way of Betamax

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:

Silverlight RadScheduler RIA App Part 3

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!