After reading the first part of this series, you should now have a project that is ready to wire up with events. In summary, last time we:
Now, we get to the fun part and can start wiring up some of the events we set in the last post. The first thing that we need to do is to handle when our DomainDataSource loads its data. In our Silverlight application we set an Appointment (from Telerik.Windows.Controls.Scheduler) observable collection to be used across the board (named myApps for future reference), but the data coming back from our DomainDataSource is coming back in SqlAppointments. This is easy to work with, as we run a simple foreach on the data coming back as follows:
If only it were that easy! :)
We actually need to convert our appointments from SqlAppointments to regular Appointments, which we can do pretty easily:
The next step is handling recurrence... Now, you could go the easy way and disable recurrence, but that wouldn't make our scheduling application too powerful, now would it? Thankfully, the RadScheduler team has provided us with RecurrencePatternHelper to come to the rescue. This serves two purposes- first, it can convert a recurrence pattern into a serialized string for storage, and second it lets you take that string back into your application and turns it into a pattern to use for your recurrence rule.
This brings us to a whole new topic- handling recurrence exceptions. Yes, recurrence is a great and wonderful thing, but if you didn't have the ability to make modifications to your appointments- say, you have a daily morning appointment, but every so often one includes people from another team and you want that in the reminder. Exceptions are another beast entirely, but not quite so difficult to deal with. To work with this concept, I created the RecurrenceExceptionHelper class to do something very similar to what the RecurrencePatternHelper class does- it takes appointment exceptions and serializes them into a string for storage, then on the return trip it can take that string and turn it into a string of appointment exception occurrences. I won't bore you with the details of how that works right now (I'll save that for the next post), but keep in mind it will be present in the example here so you can ignore the magic it is doing behind the scenes.
Back from that tangent, along with the recurrence pattern we need to load exceptions into the appointment so that RadScheduler knows where the abormalities are and how to show them. Once that is complete, we add our appointments to the myApps collection and set that as the AppointmentsSource of RadScheduler, kinda like this:
Now we've got the ability to bring appointments back from the database. But wait, how do we save appointments to the database, edit them or delete them? Stay tuned to part three of this series for the RadScheduler events that will pull this all together and give you your RIA-ified RadScheduler that will be the basis of the rest of this series.
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.