Between the last post and this one I went ahead and carried the ideas for the Jobs module and view into the Applicants module and view- they're both doing more or less the same thing, except with different objects being at their core. Made for an easy cut-and-paste operation with a few items being switched from one to another. Now that we have the ability to add postings and applicants, wouldn't it be nice if we could schedule an interview? Of course it would!

Scheduling Module

I think you get the drift from previous posts that these project structures start looking somewhat similar. The interview scheduling module is no different than the rest- it gets a SchedulingModule.cs file at the root that inherits from IModule, and there is a single SchedulerView.xaml and SchedulerViewModel.cs setup for our V+VM. We have one unique concern as we enter into this- RadScheduler deals with AppointmentsSource, not ItemsSource, so there are some special considerations to take into account when planning this module.

First, I need something which inherits from AppointmentBase. This is the core of the RadScheduler appointment, and if you are planning to do any form of custom appointment, you'll want it to inherit from this. Then you can add-on functionality as needed. Here is my addition to the mix, the InterviewAppointment:

01.publicclassInterviewAppointment : AppointmentBase

02.{

03.privateint_applicantID;

04.publicintApplicantID

05.{

06.get{ returnthis._applicantID; }

07.set

08.{

09.if(_applicantID != value)

10.{

11._applicantID = value;

12.OnPropertyChanged("ApplicantID");

13.}

14.}

15.}

16.

17.privateint_postingID;

18.publicintPostingID

19.{

20.get{ return_postingID; }

21.set

22.{

23.if(_postingID != value)

24.{

25._postingID = value;

26.OnPropertyChanged("PostingID");

27.}

28.}

29.}

30.

31.privatestring_body;

32.publicstringBody

33.{

34.get{ return_body; }

35.set

36.{

37.if(_body != value)

38.{

39._body = value;

40.OnPropertyChanged("Body");

41.}

42.}

43.}

44.

45.privateint_interviewID;

46.publicintInterviewID

47.{

48.get{ return_interviewID; }

49.set

50.{

51.if(_interviewID != value)

52.{

53._interviewID = value;

54.OnPropertyChanged("InterviewID");

55.}

56.}

57.}

58.

59.publicoverrideIAppointment Copy()

60.{

61.IAppointment appointment = newInterviewAppointment();

62.appointment.CopyFrom(this);

63.returnappointment;

64.}

65.

66.publicoverridevoidCopyFrom(IAppointment other)

67.{

68.base.CopyFrom(other);

69.var appointment = other asInterviewAppointment;

70.if(appointment != null)

71.{

72.ApplicantID = appointment.ApplicantID;

73.PostingID = appointment.PostingID;

74.Body = appointment.Body;

75.InterviewID = appointment.InterviewID;

76.}

77.}

78.}

Nothing too exciting going on here, we just make sure that our custom fields are persisted (specifically set in CopyFrom at the bottom) and notifications are fired- otherwise this ends up exactly like the standard appointment as far as interactions, etc. But if we've got custom appointment items... that also means we need to customize what our appointment dialog window will look like.

Customizing the Edit Appointment Dialog

This initially sounds a lot more intimidating than it really is. The first step here depends on what you're dealing with for theming, but for ease of everything I went ahead and extracted my templates in Blend for RadScheduler so I could modify it as I pleased. For the faint of heart, the RadScheduler template is a few thousand lines of goodness since there are some very complex things going on in that control. I've gone ahead and trimmed down the template parts I don't need as much as possible, so what is left is all that is relevant to the Edit Appointment Dialog. Here's the resulting Xaml, with line numbers, so I can explain further:

The first line there is the DataContextProxy I mentioned previously- we use that again to work a bit of magic in this template.

Where we start getting into the dialog in question is line 132, but line 407 is where things start getting interesting. The ItemsSource is pointing at a list that exists in my ViewModel (or code-behind, if it is used as a DataContext), the SelectedValue is the item I am actually binding from the applicant (note the TwoWay binding), and SelectedValuePath and DisplayMemberPath ensure the proper applicant is being displayed from the collection. You will also see similar starting on line 420 where I do the same for the Jobs we'll be displaying.

Just to wrap-up the Xaml, here's the RadScheduler declaraction that ties this all together and will be the main focus of our view:

Now, we get to the ViewModel and what it takes to get that rigged up. And for those of you who remember the jobs post, those command:s in the Xaml are pointing to attached behavior commands that reproduce the respective events. This becomes very handy when we're setting up the code-behind version. ;)

ViewModel

I've been liking this approach so far, so I'm going to put the entire ViewModel here and then go into the lines of interest. Of course, feel free to ask me questions about anything that isn't clear (by line number, ideally) so I can help out if I have missed anything important:

One thing we're doing here which you won't see in any of the other ViewModels is creating a duplicate collection. I know this is something which will be fixed down the line for using RadScheduler, simplifying this process, but with WCF RIA changing as it does I wanted to ensure functionality would remain consistent as I continued development on this application. So, I do a little bit of duplication, but for the greater good. This all takes place starting on line 79, so for every entity that comes back we add it to the collection that is bound to RadScheduler.

Otherwise, the DelegateCommands that you see correspond directly to the events they are named after. In each case, rather than sending over the full event arguments, I just send in the appointment in question (coming through as the object obj in all cases) so I can add (line 91), edit (line 119), and delete appointments (line 142) like normal. This just ensures they get updated back to my database. Also, the one bit of code you won't see is for the Appointment Creating (line 110) event- that is because in the command I've created I simply make the replacement I need to:

And the ViewModel is none the wiser, the appointments just work as far as it is concerned since as they are created they become InterviewAppointments. End result? I've customized my EditAppointmentDialog as follows:

And adding, editing, and deleting appointments works like a charm. I can even 'edit' by moving appointments around RadScheduler, so as they are dropped into a timeslot they perform their full edit routine and things get updated.

And then, the Code-Behind Version

Perhaps the thing I like the most about doing one then the other is I get to steal 90% or more of the code from the MVVM version. For example, the only real changes to the Code-Behind Xaml file exist in the control declaration, in which I use events instead of attached-behavior-event-commands:

01.<telerikScheduler:RadSchedulerx:Name="xJobsScheduler"

02.Grid.Row="1"

03.Grid.Column="1"

04.Width="800"

05.MinWidth="600"

06.Height="500"

07.MinHeight="300"

08.EditAppointmentStyle="{StaticResource EditAppointmentStyle}"

09.AppointmentAdded="xJobsScheduler_AppointmentAdded"

10.AppointmentCreating="xJobsScheduler_AppointmentCreating"

11.AppointmentEdited="xJobsScheduler_AppointmentEdited"

12.AppointmentDeleted="xJobsScheduler_AppointmentDeleted">

13.</telerikScheduler:RadScheduler>

Easy, right? Otherwise, all the same styling in UserControl.Resources was re-used, right down to the DataContextProxy that lets us bind to a collection from our viewmodel (in this case, our code-behind) to use within the DataTemplate. The code conversion gets even easier, as I could literally copy and paste almost everything from the ViewModel to my Code-Behind, just a matter of pasting the right section into the right event. Here's the code-behind as proof:

One really important thing to note as well. See on line 51 where I set the DataContext before the Loaded event? This is super important, as if you don't have this set before the usercontrol is loaded, the DataContextProxy has no context to use and your EditAppointmentDialog Job/Applicant dropdowns will be blank and empty. Trust me on this, took a little bit of debugging to figure out that by setting the DataContext post-loaded would only lead to disaster and frustration. Otherwise, the only other real difference is that instead of sending an ActionHistory item through an event to get added to the database and saved, I do those right in the callback from submitting.

The Result

Again, I only have to post one picture because these bad boys used nearly identical code for both the MVVM and the code-behind views, so our end result is...

So what have we learned here today? One, for the most part this MVVM thing is somewhat easy. Yeah, you sometimes have to write a bunch of extra code, but with the help of a few useful snippits you can turn the process into a pretty streamlined little workflow. Heck, this story gets even easier as you can see in this blog post by Michael Washington- specifically run a find on 'InvokeCommandAction' and you'll see the section regarding the command on TreeView in Blend 4. Brilliant! MVVM never looked so sweet!

Otherwise, it is business as usual with RadScheduler for Silverlight whichever path you're choosing for your development. Between now and the next post, I'll be cleaning up styles a bit (those RadComboBoxes are a little too close to my labels!) and adding some to the RowDetailsViews for Applicants and Jobs, so you can see all the info for an appointment in the dropdown tab view. Otherwise, we're about ready to call a wrap on this one

About the author

Evan Hutnick

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.

RadScheduling has definitely moved on to a much more advanced control - the RadScheduleView that you had mentioned. Right now I'd suggest keeping in step with the material we're putting out for RadScheduleView. The reason for that use of DelegateCommand was to utilize Prism to capture events into behaviors that can be responded to via Commands on the viewmodel. Stay tuned though, this HR app concept hasn't gone away, we've just been putting out a number of awesome new controls in the last so long and are beginning to cook up something pretty interesting in regards to how to utilize the RadControls for SL (or WPF) in a nice integration scenario.