Web RSS Builder Part 3: The Silverlight Application

• Download application source on CodePlex

Introduction

Web RSS Builder is an open source application for managing RSS files using Web-based and Silverlight-based interfaces. This application is useful when you need to manage RSS files on the server using a web application.

The application is hosted on CodePlex at http://WebRSSBuilder.codeplex.com.

This is part 3 of a three-part post that will describe this application:

• Web RSS Builder Part 1: Generic XML data source for ASP.NET and Silverlight
• Web RSS Builder Part 2: The ASP.NET Application
• Web RSS Builder Part 3: The Silverlight Application

The Silverlight Application

Thinking Silverlight-ly!

When you work with Silverlight, you have to think differently than typical web development, now you have a client and a server that can be connected somehow (using Web services or anything else). If you are not familiar with Silverlight, I would suggest you go try to read about it first since this article is not intended to explain what Silverlight is. Often, when you read or watch videos about data binding in Silverlight, the examples are going to be binding to a database or binding to an Entity framework object. As for other data sources, such as XML files, I did not came across any standard or out-of-the-box technique to be used directly. So I was trying to explore different ways of binding XML files in Silverlight, I will discuss what were the options, what I chose, and most importantly why I chose it.

What is the Difference between MVC and MVVM?

With the introduction of XAML in WPF and Silverlight, Microsoft intended to make a clear distinction between the view, or how to present data, and whatever other logic or process may be needed on this data, to increase the decoupling of your application and to increase the reusability, your view should always care about how to present data, nothing more.

But that was the view job in MVC, so what is the difference?

The difference is simply that data which is presented in your model is always dependent on some data source, whether a table on database, an XML schema, or something else. However, this data can be viewed on different perspectives. You can have a Model as a Customer, and then you need to view this customer based on different locations, sales, or orders, etc... To be able to do that before, you ended up writing some code in Views to filter based on your preferences.
In MVVM, you can just simply define a ViewModel that filters the data based on your choice and the view won’t have to deal with that.
This is one reason why MVVM is different that MVC, another reason is inherent in the technology that lead to MVVM, if you compare traditional ASP or Windows forms binding and event handlers it’s almost impossible to have a Windows form, or an ASP.NET page without any code in the code behind.

You may ask why should I in the first place?

Well the answer is simple, because it’s a WEB PAGE, it’s WINDOWS FORM, it’s a view. It’s not the logic of your application. Why should you then? You are just viewing data? Why not the view have a technique to plug-in whatever functionality you want to provide when, by example, clicking on a customer. So here, the whole concepts of Command and Data Context are introduced in XAML to give it the support for MVVM.

MVVM Pattern for XML Data Service: WCF or Domain Data Services?

We are going to use the core component to provide data to the Silverlight application using the MVVM pattern. First let’s explore different ways of binding data to a Silverlight application:

1. Using Domain data services: it requires entity framework
2. Using WCF Data service: it requires entity framework or object implementing IQuerable
3. Using WCF web service
4. Implementing you own connector: such as a socket or something else

The first option was not meant to be in our case, since we don’t have an Entity framework data source. The fourth was too much work (reinventing the wheel). I had the chance between implementing IQuerable data source, or going with a simple WCF web service, I chose the latter. It seemed like less work.

The WCF Web Service

The WCF web service was actually simple, just encapsulating the controller RSSFeedXLinqController for loading or saving a specific file.

[OperationContract]
public RSSFeed GetRssFeed(int FileID)
{
 DomainServiceDB d = new DomainServiceDB();
 File f = d.GetFileByID(FileID);
 if (HttpContext.Current.User.Identity.IsAuthenticated)
   if (HttpContext.Current.User.IsInRole(f.aspnet_Roles.RoleName))
      return new RSSFeedXLinqController().LoadRss(f.FileURL);
 else
       throw new Exception("Access Denied");
 return null;
}

The ViewModel

The RSSViewModel implements INotifyPropertyChanged to inform the View controls with any change in the data. The RssViewModel contains a Feed object which is our Model, a Load Command and Save Command, and a PagedCollectionView that’s for the RSSItem, I used this object to allow paging.

public class RSSViewModel: INotifyPropertyChanged
{
  private RSSFeed feed;
  private bool isChanged;
  public bool IsChanged {..}
  WCFRSSDataSourceClient client;
  public DelegateCommand LoadCommand {get; set;}
  private PagedCollectionView itemsPaged;
  public PagedCollectionView ItemsPaged {....}
  public DelegateCommand SaveCommand { get; set; }
  public RSSFeed Feed {..}
  public event PropertyChangedEventHandler PropertyChanged;
  ...

The main methods in this class are to Load and Save the file which is simply establishing the connection with the Web Service.

private void LoadRSS(object Parameter)
{
   client = new WCFRSSDataSourceClient("CustomBinding_WCFRSSDataSource1");
   client.GetRssFeedCompleted += new EventHandler(client_GetRssFeedCompleted);
   client.GetRssFeedAsync(((File)App.Current.Resources["File"]).FileID);
}

public void SaveRSS(object Parameter)
{
  client = new WCFRSSDataSourceClient("CustomBinding_WCFRSSDataSource1");
  client.UpdateRssFeedCompleted +=new EventHandler   client_UpdateRssFeedCompleted);
  client.UpdateRssFeedAsync(feed, ((File)App.Current.Resources["File"]).FileID);
  ...

Is Domain Data Service MVVM Friendly?

As for the other managing pages, such as Manage files and Manage Roles, I used domain data services to bind to the data source.

Well people could argue if Domain Data Service is MVVM friendly? And whether we should implement a ViewModel for domain data service or not? I personally think, it depends; If you are going to view the model as is, there is no need to make a ViewModel just to mock the model and to establish the connection since an embedded mechanism is implemented to declare a domain data source in XAML, so since patterns are there to make our life easier pages like Manage Roles and Manage Files won’t have any ViewModel, and still you can open the code behind and see that’s still empty. So I am still following the concept of code-less views. However, in other cases such as the homepage case, where I need to view files based on the user logged in, I created a ViewModel for the Domain Service to filter the user.

Using Combo box in Data Form: The Problem and the Solution

I encountered one problem that was worth mentioning while I was using a combo box inside a data form which is bound to a Domain data service. For some reason, the key value of this combo box is not changed when the user changes the combo box. And I kept looking for a solution for almost 4 hours before I found one. To bind combo box inside a Data form:

< combobox name="combobox2" itemssource="{Binding Source={StaticResource RoleSource},
   Path=Data, Mode=OneWay}" selecteditem="{Binding Path=RoleID, Mode=TwoWay,
   Converter={StaticResource RoleConverter}, NotifyOnValidationError=True,
   ValidatesOnExceptions=True}" displaymemberpath="RoleName"
   selectedvaluepath="RoleId" />

1. The Items source should be bound to the data source that contains both the Key and the Value with a one way binding mode.
2. The Display Member path should contain the value field name.
3. The Selected Value Path should contain the key value field.
4. Most importantly, you should define a converter that will take the Key (Item ID in my case) and returns the item object and vice versa.

Conclusion

I hope that this application would be beneficial to whoever needs it. Your feedback to make this application better and to discuss the concepts addressed in these posts is highly appreciated.

Did You Like the Article?

If you did, please vote for it. :)