Random Blurbs and things of this Nature

Starting with RIA Services

2010-02-18T18:53:00.001-08:00

I am planning to speak at The New York City Code Camp on March 6, 2010, my topic will be Developing Rich ASP .NET Web Applications with Coolite”. To challenge myself before this I decided to experiment with Silver Light RIA Services in creating a small Silver Light application to get the data into the database. I have some initial thoughts on RIA Services being something that I played with in the past and now. I felt it would be good to write a blog entry to share my thoughts on the idea and how it works, also ask some questions.

So let me first state that I think RIA services is a great idea, and is a step in the right direction. The reason for this is that it seems no matter what tools we create or how much we abstract the application requirements continue to increase. This is because as we get better at using our tools we find ourselves able to focus more on the applications at hand, when this happens inevitably we think of bigger and better things. So of course, this is a vicious cycle, as we get more time we use it to make things more complex; being a developer is fun :)

If you have ever made any kind of advanced web application that leverages the principles fundamental to Web 2.0 you know that it always takes a lot of code and tends to lead to some coupling that is undesirable. To counter this Microsoft is working on a new idea for its Silver Light platform that automates much of the communication between the front end application and the server. Its purpose is to open the door for Silver Light to be used in Line of Business applications.

RIA Services is centered around the idea of Domain Context objects, which are representations of decorated backend Domain Services classes. When the application is built, Visual Studio will use its internal T4 template generation engine to generate code within the Silver Light project. This code can then be used and it automatically takes care of the process of connecting to the server and getting its data via WCF RIA Data Services.

Now, I cannot tell you how many times this has been attempted by someone somewhere, every month it seems a new framework comes out that promises to change the way we develop the web, never does. RIA services has a lot of momentum but it is not easy to get started. There are a lot of gotcha, mainly because it is still so new and has a lot of things in flux. .NET 4 promises the first finalized release version integrated into the .NET framework.

I earnestly look forward to some additional development in this area as I think it is very important. With the, pardon me, failure, of MS Ajax Microsoft made a great move to accept JQuery as the JavaScript framework of choice for ASP .NET web apps, now we see them developing a framework to help RIA development in the sandbox approach. We can hope for a better outcome for the RIA services.

Understanding Co and Contra Variance in .NET 4

2010-02-09T19:29:00.001-08:00

Of all the features that are coming in .NET 4, perhaps the one that is the most exciting to me is Covariance and Contravariance. So why does this excite me more then EF and other new features coming; cause for those of us who leverage generics and polymorphism the updates to variance are a god send. Consider the following example:

This is the abstract class we are going to demonstrate against:

public abstract class Vehicle
{
     public abstract int NumberOfWheels { get; }
     public abstract void Turn(string direction);
     public string Name { get; set; }

     public virtual void Drive()
     {
          Console.WriteLine("Driving Vehicle");
     }
}

We create the following concrete classes defined using the Vehicle abstract class:

public class Car : Vehicle
{
     public override int NumberOfWheels
     {
          get { return 4; }
     }

     public override void Turn(string direction)
     {
          Console.WriteLine("Turning " + direction + " on " + NumberOfWheels + " wheels");
     }

     public override void Drive()
     {
          Console.WriteLine("Driving the Car");
     }
}

public class Truck : Vehicle
{
     public override int NumberOfWheels
     {
          get { return 6; }
     }

     public override void Turn(string direction)
     {
          Console.WriteLine("Truck is Turning " + direction + " on " + NumberOfWheels + " wheels");
     }

     public override void Drive()
     {
          Console.WriteLine("Driving the Truck");
     }
}

Now, we will define an extension method to operate on both of these types, we can do this by operating on the abstract Vehicle type:

public static void DriveAll(this IEnumerable<Vehicle> listing)
{
     foreach (Vehicle v in listing)
     {
           v.Drive();
     }
}

So given all this, you might expect this bit of code to compile in C#:

static void Main(string[] args)
{
     List<IVehicle> carList = new List<IVehicle>()
                                    {
                                        { new Car() { Name = "Nissan Sentra" } },
                                        { new Car() { Name = "Volkswagon Passat" } },
                                        { new Car() { Name = "Toyota Camry" }}
                                    };

     carList.DriveAll();
     Console.Read();
}

You would be wrong, this code does not compile because .NET 3.5 does not support covariance and contravariance. This means that .NET will ONLY analyze the outer type in this case, so IEnumerable<T> and not look at the inner type which would allow it to know that since Car inherits from Vehicle this is ok. To get around this we employ a interface trick to allow us to control the inner type and “trick” .NET. To do this, we first need an interface:

public interface IVehicle
{
     int NumberOfWheels { get; }
     void Turn(string direction);
     void Drive();
}

Next we update the Vehicle definition to implement the IVehicle interface like such:

public abstract class Vehicle : IVehicle
{
     // ...
}

By doing this we are able to constrain the inner type and control it. The key thing to understand here is that the extension method is attempting to find a similar signature to attach to, with thus approach we can give it that, while still keeping the flexibility of working with all types inheriting Vehicle. This is our updated signature:

public static void DriveAll<T>(this IEnumerable<T> listing) where T : IVehicle
{
     foreach (T v in listing)
     {
          v.Drive();
     }
}

To understand what is happening here, we are effectively taking control over the inner type through generic constraints. By doing this we are able to provide the signature that .NET 3.5 will need need to provide the extension. In addition, since we are using the constraint we maintain the flexibility and requirements for the internal type.

However, in .NET 4 where we have covariance and contravariance, we don't need the interface approach through a generic method. The inspection of the extension method will encompass an analysis of the internal type to determine the inheritance. This is already being done in 3.5 on the outer type (try using IEnumerable<T> for List<T>), in .NET 4 we are now having it done on the internal type as well.

How Can Extension Methods Help You?

2010-01-31T12:48:00.001-08:00

I am a huge proponent of extension methods in .NET (and other languages). I believe they are a gateway to making complex code easier to follow and understand, also helps to maintain the object oriented paradigm that .NET is built on. They are also key to the notion of Fluent APIs which has been permeating throughout the programming space for the past year or so.

The idea of a Fluent API is an API that reads very much like an English sentence and is considered a tremendous advancement in readable code.

string value = "500";
int myValue = value.AsInt();

This is a sample code snippet that you see a lot in my projects as I tend to work a library I have created which contains many extension methods for formatting and parsing of values. Notice how as you read the code it flows and its concise with the parsing logic centralized. Traditionally you might have seen code such as this:

string value = "a500";
int myValue = int.MinValue;
int myValue = int.MinValue;

int.TryParse(value, out myValue);
myValue = Convert.ToInt32(value);

Using TryParse, which is a standard method common to all primitive value types in .NET, this code does not throw an exception and myValue has a value of zero at operations end. I dont like this because I would expect TryParse to leave the value of myValue unchanged if the parse fails, it does not. As for the use of Convert it basically emulates what would happen if you called int.Parse on this value, it throws a FormatException.

In addition to the obvious problems of repeating this code anywhere you need to parse an int from a string, I find this to be very procedural. Now there is no question that all programming, no matter how hard we try is going to be at some level procedural, however, my goal is always to minimize such code and keep things as Object Oriented as possible, after all that is what OO languages are designed for and, not surprisingly, very good at.

Extension methods are also exceptionally useful for custom formatting and outputting for certain types. For example, lets say you wanted to output a DateTime object is standard notation for the United States, mm/dd/yyyy. Well simply calling ToString(“d”) easily accomplishes this. But littering your code with this code could turn into a potentially horrendous maintenance problem if your boss decides it ought to be dd/mm/yyyy (which is common in Europe), but use an extension method and your code could look like this:

DateTime dt = new DateTime(1983, 1, 13);
Console.WriteLine(dt.AsStandardFormatString());

Using this approach you can have a standard way out outputting a DateTime, perhaps stored somewhere in a different project, that you can easily update, perhaps make culture aware, all without your application ever being the wiser.

So, while Extension Methods are very useful for type conversion libraries and provides standardization out formats and outputs for types, they have another great use. Provides reusable ways to affect changes on objects, collections in particular, while maintaining a very clean interfaces and emphasizing “changes as a unit of work”. I am sure someone has published something relating to the notion of change as a unit of work, but let me elaborate a little further.

The idea of change as a unit of work derives from the Single Responsibility Principle and Open Closed Principle laid out by Robert Martin. The idea is that everything has one responsibility and it should carry out that responsibility effectively and thoroughly, from the construction of methods to the definition of classes, they amalgamation of these constructs comprises the application and only by working together can they do such. Consider the following pieces of code that comes from some code that I wrote this week for a rather complex process that I am working on at work.

var scheduleList = dayList.GroupByShiperId().ConvertToSchedule();

(For those concerned, yes I did mutate this code so that it does not reflect what was actually written).

The idea here is to take a very complicated process and break it down into smaller units and then create functions to carry out those units of work. Hence any changes to the information is a unit of work. Easily testable and thanks to extension methods, very clean from an API standpoint. But extension methods are only a small part of this process, understanding the interfaces and classes you have available to you is critical as well as it can help you move code to where it should be. The method in question could easily have been a 200 line function that would have been a nightmare for anyone to maintain. Instead its five functions, all with less then 12 lines working together and producing a result.

Using this approach you can be less procedural in your code and leverage the object oriented paradigm of the .NET framework and help people who will come after you understand what is happening. Thus together with good function naming, you can create similar clean reusable APIs for your projects and further leverage the concept of change as a unit of work.

Thoughts on CodeMash 2010

2010-01-17T19:14:00.001-08:00

As CodeMash 2010 has come to a close I would like to take some time to reflect on the conference. This year was, in my opinion, not quite as good as last year but a lot of fun. I think this year more people decided to really forgo the sessions and focus on the networking and social interactions that really define what CodeMash is. To me CodeMash has ALWAYS been about the people; people that you meet and the people you get to talk to and learn from. So that said, I didnt feel the sessions were quite as good as last year, so we will look forward to next year.

One thing that did happen was I did my first ever open spaces sessions where I spoke on Developing for Android. Considering I decided I want to talk about it earlier in the morning and did no formal preparation, it went very well. I had about 20 people around me and we just talked. I explained some of the things I have discovered in developing CodeMashDroid and really perked the interest for a lot of people. I really want to speak next year, but for right now I am preparing to submit my first abstract to the New York City Code Camp, which would give me a chance to really push RCM’s name for web development in the New York area. But I digress. Speaking of CodeMashDroid, I was amazed at how many people had Droids at the conference. It really is nice to see that Android is making good success against ATT.

I was also not the only one to develop a mobile application for Droid, as an entire company decided to get involved in the development. I also missed the emails about posting information on the app so other would know where to find it, in addition I targeted only Android 2.0+ so I limited myself to those with Droids or newer; but its good to take away lessons from such an experience. I also learned about some of the shortcomings in my test methodology and emulator capabilities.

Overall, CodeMash was a great experience and I look forward to the same experience next year. I will be posting my pictures to Facebook later this week as well as hopefully getting time to write up a few blog entries elaborating on the topics I spoke about in my Open Spaces discussion.

Introducing CodeMashDroid

2010-01-13T13:22:00.001-08:00

I am pleased to announce the release of a new app in the Android app store which I have entitled CodeMashDroid. This app was developed in response to the request from the CodeMash organizers that attendees develop a solution for managing the CodeMash schedule using a REST API containing information for all conference information. In addition, I had just purchased a Motorola Droid and was curious in entering the world of modern mobile development. So I set out to create such an application.

As I developed the application I began to think about the fact that each time I went to a conference we were always being handed a piece of paper with the schedule or people would use their laptops to look up times. It seems with the prevalence of cell phones, especially in the geek community, the smart handset could be used to manage this information and be used to alert people if they are missing something. Think of it as a specialized calendar, or even better based on what suggestion, allow integration with Outlook, gCal, and iCal. From this feedback and train of thought the idea for a conference managing application was born. CodeMashDroid is a proof of concept app for this idea, and should it prove successful the project will officially kick into gear after CodeMash when we have collected feedback.

To download this app please look for it in the Android App store, it is free and we welcome any feedback as we decide on how to move forward. Please leave these comments in the AppStore feedback section, we will be monitoring this and will work the features into planning as we move forward. We also welcome naming suggestions as I have no idea what I am going to call this yet :)

Thanks

2009 Year in Review

2010-01-01T17:20:00.001-08:00

Its amazing how much has changed in my life this decade, even in the last year. We all know how 2009 was bad for a lot of people and at the start there was much we wondered about. For me, 2009 was a year of redemption, a chance to make my mark and advance in my industry. When 2008 ended I had narrowly avoided being laid off from my company, and now as we ring in 2010, I feel that I can breath easy with a fair amount of job security. Many other things occurred so I thought I would publish a year in review posting for this pivotal year.

Job Questions
As December of 2008 came around I already had a feeling that I would be included in the layoffs. I hadn't really been on a billable project in quite some time and though the work I had done was valuable from a process standpoint, as a consultant it really comes down to billable hours. I steeled myself for the outcome which came to fruition. But all was not lost to me, I continued to work even after I was told I didn't have to, I wanted to finish this final feature I was working on, as a token of thanks to the company that gave me my start. As I started looking around I had garnered much interest from the tech community and my transition to a new company seemed assured when I caught a most fortunate break. I received a phone call from our head manager in Grand Rapids who asked me if I would like my job back. I was taken aback by this and asked for some time as I was considering other offers. But the more I thought about it, the more I wanted to be at RCM, I felt it was the best place to learn and grow.

So I had a conversation in which I asked the reasons behind the decision to let me go, it was because they had not put me on work because of the good work I was doing to improve process. I said to them that if I were to come back, I would not like it if I were simply laid off again for the same reasons, something must change. And so it did. From the get-go they were true to their words and through work at me and I thrived. I worked on one of the biggest projects the company had that year, and it became the most successful, a testament to good planning and a well organized team.

Then came another challenge, we had a client who wanted something done but only PHP could be used due to the existing technologies. This time I pulled out the skills that I had not used since converting to a .NET programmer (heavily anyway) and created a well architected easily extensible enhancement to an existing software product, this time working remotely in more of a leadership role for my potion of the project, again I thrived. My boss, who had always believed in me, was thrilled, I was starting to really carve out a niche for myself. Then it came, the need for someone to go to New York to work on a huge project for another division in RCM, one under the direct supervision of the RCM brass. After a long interview process, I was chosen and so as I close 2009, I look back on the great breaks I had knowing full well that my positioning had a lot more to do with getting them then luck.

Preparations for Japan
With questions about my employment swirling at the end of 2008, my Japan trip for 2010 was also placed in doubt. Once the employment situation stabilized, the stability led to me beginning to take the steps to prepare for my trip to Japan. The first step was to refresh my knowledge of the Japanese language through study. To aid in this study I purchased Rosetta stone with levels 1, 2, & 3 and immediately began my training. The remote work in New York helped bolster my accounts and allowed me to purchase a new camera which is something that I indicated was necessary for my trip. And now, as we enter the new year I am preparing final preparations for plane tickets and ryokan, hostel, and hotel reservations following CodeMash. In addition, I am preparing for the final purchase, a Netbook to help with blogging details of my journey. Truly 2009, was a great year that saw me take great strides in preparing for my trip. The final detail that solidified my desire to go was learning that my host brother and sister would be graduating from juugaku (middle school) and shogaku (elementary school) and thus I would be in country and able to attend a juugaku entrance ceremony, and a kookoo (high school) entrance ceremony. This is very exciting.

Final Reflections
I generally tend to think that each year should bring knowledge and new experiences from which you should grow as a person. And you should be proactive in seeking these experiences and seeking new challenges to increase your knowledge. I feel that in the past year I have done this and grown as a person. I hope to continue to increase my experience and knowledge in 2010 by continuing to challenge myself professionally and grown from the experiences I will have in Japan. Happy New Year everyone, have a happy 2010.

The Android Experiment

2009-12-13T17:30:00.001-08:00

Mobile development is something that I have always wanted to try, but I never owned a smart phone and so really had no deep drive to develop mobile applications. This all changed recently when I purchased a Motorola Droid and immediately began playing with the Android OS and developing applications for various purposes; mainly for conference management. I have always hated how I would go to a conference and I would receive a piece of paper of have to check a website to know what sessions happened when. I set out to create an Android app to help me manage the sessions available for the Codemash conference that I attend annually.

Setting up the Environment
The first step for me is always to set up an IDE and as is the case with most non-Microsoft products and technologies, the IDE in use will be Eclipse. I am not an overly big fan of Eclipse, mostly because I have been spoiled by Visual Studio, but it is a very useful tool for developing. Aside from Eclipse you will also need the Android 2.0 SDK which will provide you with the emulator necessary for testing your app. I found this links helpful in walking me through the process of setting things up: http://developer.android.com/guide/developing/eclipse-adt.html

Understanding Android Applications
The first thing to understand about Android apps is they are centered around an Activity. An application can have many activities of differing types. In general you will use a vanilla Activity, but other activity types, such as ListActivity, are also available. The primary functions of the Activity class is the onCreate functions which you will override to perform tasks associated with the app startup. Creating an Android Project in Eclipse you will see your onCreate method defined as such:

@Override
public void onCreate(Bundle savedInstanceState)
{
     super.onCreate(savedInstanceState);
     setContentView(R.layout.main);
}

The value being passed into setContentView is actually an integer which maps to a special class called “R” which contains mapped elements from the layout, I will elaborate more on this in the next section.

Understanding the layout
The layouts in Android can be defined in the program if desired but Android also supports defining the layout in XML. By default, Eclipse will create a layout file called main in a directory called “layout” in a special folder called “res”. Now look above at what is being passed to setContentView. A special class called R is maintained by Android which contains references to elements in the view. This makes it easier to references the items in the layout.

The next thing to understand is that everything that can be shown to the user or used to control the structure of the UI is a “view”. TextView for example is used to show text, Button is a view which is used to represent a button, ListView which is a list of items. Views can have IDs which can be added to R and allow them to be easily referenced in the code. LinearLayout is also a view. The important thing to remember when defining your layout in XML is all elements must define a layout_width and a layout_height. If you fail to do this, your application will crash on startup when the content view is loaded.

Understanding Population of ListView
I want to talk about this as it caused a significant amount of pain for me when I was learning it, though looking back I am confused as to why it did, but that is normal I suppose :). So the first thing to understand is if you are from the .NET world, throw what you know away since Android prefers to make the population of a List as complicated as possible.

First you need to have a ListView on the page, as you might expect. Next if your activity does not derive from ListActivity you will need to create an Adapter class. The following is my definition for the adapter I use in my CodeMash app:

public class CustomListAdapter<T> extends BaseAdapter
{
     @Override
     public int getCount()
     {
          return _data.size();
     }

     @Override
     public T getItem(int position)
     {
          return _data.get(position);
     }

     @Override
     public long getItemId(int position)
     {
          return position;
     }

     @Override
     public View getView(int index, View renderer, ViewGroup parent)
     {
          TextView view = new TextView(this);
          return view;
     }
}

This example uses generics for the internal list that will be applied to the ListView, but it is not required. Here are some additional things that must be added to the class to make it work.

Create a constructor that takes as parameters a reference to the Activity that is called it, a parameter to hold the list you are going to bind to the ListView, and finally a reference to the ListView that we are going to bind to.
The most important thing to do is store references to the Activity and the data internal within the class, as they will be referenced and needed throughout. You must also call the setAdapter method of the ListView reference and pass as a parameter “this”.

You will notice that inheriting from the abstract class BaseAdapter will require the implementation of several abstract methods: getCount, getItem, getItemId, getView. Here is an explanation of these functions:

getCount()

This function is responsible for returning the size of the underlying data set

getItem(int position)

This function is responsible for returning an object from the underlying data set at a given position

getItemId(int position)

This function is responsible for returning an identifier for the selected object at a given position. In most of my examples I just return the position that was passed, depends on if I have a key to pass out.

getView(int index, View renderer, ViewGroup parent)

This is the most important function in the adapter, it allows you to define the ItemRow, that is how each item in the dataset is represented in the ListView. Most often you will do this programmatically, though I have been working with XML inflation and that shows promise of removing UI building code from the code, which I think helps forge good separation.

So the basic idea with the adapter is to pass in the data, the activity, and the ListView that you intend to reference and use. You then make a simple call to setAdapter and read your data from within the object creating a view to represent the object for each row in the ListView using the getView method required by the BaseAdapter abstract class.

Conclusion:
My general feelings toward developing on Android are a mixture of annoyance and sheer fun. On the one hand it is nifty to develop applications for a mobile platform and Android has a wide assortment of features to help you. On the other hand, I have never been a fan of Java as it feels like a hack next to C# and the absence of the many native syntax features in Java makes some development difficult. Some of the common things seem more difficult then they should be, but that could be that coming from Silverlight and Xaml, I have a higher expectation for describing layouts through markup.

Overall, I like developing in Java because of how close it is to C# and .NET, and once you get used to the way it does things like events and generics it becomes less about the language and more about the platform, which is the idea.

Separation of Responsibilities with MVC

2009-11-12T08:49:00.001-08:00

Recently I have been working on a new pattern with ASP .NET MVC, based mainly on what I have learned from MVVm and other patterns. That said, I dont know if I can really call this new, mainly because it really is an amalgamation of patterns working together to keep the architecture clean.

Step 1: The Controller Architecture
As with any system enforcement of DRY (Don't Repeat Yourself) is essential. This can be achieved any number of ways, though the most common way is the abstraction of what is repeated into a separate layer, to that end we introduce the BaseController class.

public abstract class BaseController : Controller
{
     protected ServiceController CurrentServiceController
     {
          get; private set;
     }

     public void InitalizeServiceController()
     {
          CurrentServiceController =
               ServiceController.CreateNewServiceController();
     }
     
     public void DestroyServiceController()
     {
          CurrentServiceController.Dispose();
     }
}

Some things to note here. This class is inheriting from Controller which is provided by Microsoft and is the standard class which all ASP .NET MVC Controller derive from. The two public methods we will get to later.

Step 2: Creating the Controller
ASP .NET MVC has many points of extensibility, and we will take advantage of two of them, the first one is how we “build” a controller. Whenever a request is made, MVC must determine which controller to instantiate based on the same found in the request (http://www.yourmvcwebsite.com/Series/Edit/1). Once it has this it will attempt to call the action. The reason we need to do this is for our data layer. This is a very simple instance where the Dependency Injection pattern is used, though we are choosing to not use a DI framework such as Ninject or StructureMap because our needs are simple. The goal is to set the Context reference at creation and then dispose it at release. We can achieve this by using what is already available and simply leverage basic inheritance.

public class AnimeControllerFactory : DefaultControllerFactory
{
     public override IController CreateController(
          RequestContext requestContext,
          string controllerName
     )
     {
          IController controller = base.
               CreateController(requestContext, controllerName);
          if (controller as BaseController != null)
          {
               ((BaseController)controller).InitalizeServiceController();
          }

          return controller;
     }

     public override void ReleaseController(IController controller)
     {
          if (controller as BaseController != null)
          {
               ((BaseController)controller).DestroyServiceController();
          }

          base.ReleaseController(controller);
     }
}

We could have used Reflection here to determine the type name string and then used Activator to actually get an instance, but why do that when MVC already does it for you. Thus we call the overridden method, which will return to us an instance implementing IController, from there we can do some simple casting to get to BaseController. We then call our methods which take care of the initialization process while continuing to remain unaware of what is happening. This is key, if we were to simply make a call to new() we would be coupling the two projects together, we dont want to that in our ControllerFactory.

Step 3: The Data Access Layer
One of my goals with this architecture was to totally separate generated entities from DTOs. To that end we create a “service” layer which performs the translation of a DTO to and from a Model. (Note: I tend to call my generated classes models and my DTOs entities). The following in an excerpt from the ServiceController class which acts as a “service store” for all services in the application and provides access to these services for all controllers via BaseController.

public class ServiceController : IDisposable
{
     private ServiceController()
     {
          CurrentEntityContext = new AnimeEntityContext();
     }
     
     private AnimeEntityContext CurrentEntityContext { get; set; }
     public static ServiceController CreateNewServiceController()
     {
          return new ServiceController();
     }

     #region Service References
     private SeriesService _seriesService;
     public SeriesService SeriesService
     {
          get
          {
               if (_seriesService == null)
                    _seriesService = ServiceFactory.
                         GetServiceReference<SeriesService>(CurrentEntityContext);

               return _seriesService;
          }
     }
     #endregion

     public void Dispose()
     {
          CurrentEntityContext.Dispose();
     }
}

As you can see we create a private property in this controller for the EntityContext (we are using Entity Framework for the curious). To reduce the repetitive and monotonous nature of writing the code for instantiating each Service class, I created a base class ServiceBase and then a Factory class (ServiceFactory) which takes care, generically, of setting the underlying context for those providers.

public static class ServiceFactory
{
     public static T GetServiceReference<T>(AnimeEntityContext context)
          where T : ServiceBase, new()
     {
          T returnObject = new T();
          returnObject.SetEntityContext(context);

          return returnObject;
     }
}

Step 4: The Model Binder
For the unaware, ASP .NET MVC permits a special type of parameter passing which analyzes a form collection and assigns properties based on name to an object of a given type. This instance is then passed to the action. In a previous post, it was discussed how to do this – please visit http://www.jfarrell.net/2009/10/experiments-with-asp-net-mvc-model.html

Step 5: Validation of Models
One of the most monotonous tasks of any web application is validation. As developers we cant always understand why users do what they do, but we do know we have to guard against it. How many times have you made pages which touch the same object, thus you have to violate “DRY” and you pay for it later when something changes and you forget one of the spots.

Recently one of the new ways of enforcing validation is by annotating the objects, what I mean by that is the use of attributes to describe what kind of values a property can hold. You will find these in the System.ComponentModel.DataAnnotations namespace (look for v3.5) as part of MVC 2. The following is an example of decorating a class to enforce validation.

public class SeriesEntity : IEntity
{
     // simple data references
     public int SeriesId { get; set; }

     [Required(ErrorMessage = "Series name is required")]
     public string Name { get; set; }
        
     public bool IsActive { get; set; }

     // complex data references
     public IList<SeasonEntity> Seasons { get; set; }
     
     [CollectionLength(1, ErrorMessage = "At least one Genre must be selected")]
     public IList<GenreEntity> Genres { get; set; }
     public StudioEntity Studio { get; set; }
}

Note: CollectionLength is a non-standard validation attribute

Validation takes place in the Model Binder, so we will return to the custom model binder from the referenced blog post. The OnPropertyValidating method is called for each property the binder is called to bind, thus we need to have its value first, hence the previous post will explain how to accomplish this.

protected override bool OnPropertyValidating(
     ControllerContext controllerContext,
     ModelBindingContext bindingContext,
     PropertyDescriptor propertyDescriptor,
     object value)
{
     var validationAttributes = bindingContext.Model.GetType().
          GetProperty(propertyDescriptor.Name).GetCustomAttributes(false).
          OfType<ValidationAttribute>();
     foreach (var validationAttribute in validationAttributes)
     {
          bool result = validationAttribute.IsValid(bindingContext.Model.
               GetType().GetProperty(propertyDescriptor.Name).
               GetValue(bindingContext.Model, null));

          if (!result)
          {
               bindingContext.ModelState.AddModelError(
                    propertyDescriptor.Name, validationAttribute.ErrorMessage);
               return false;
          }
     }
     return true;
}

Something that I noticed working with the standard binder is that it tends ignore properties containing complex types. That is if you had an array of type Genre, so Genre[], it would not bind because of Genre. If you instead made it int[] and gave it an array of GenreId values, it would work just fine. But I wanted to take things one step further and have my entity comeback mostly complete and not have extra properties just to support the binder. Further, I wanted to be able to validate things, hence the reason for my custom validation attribute CollectionLength.

public class CollectionLengthAttribute : ValidationAttribute
{
     private int MinLength = 0;
     private int MaxLength = int.MaxValue;

     public CollectionLengthAttribute(int minlength)
     {
          MinLength = minlength;
          MaxLength = int.MaxValue;
     }

     public CollectionLengthAttribute(int minlength, int maxlength)
     {
          MinLength = minlength;
          MaxLength = maxlength;
     }

     public override bool IsValid(object value)
     {
          if (value != null)
          {
               var collection = value as IList;
               if (collection != null)
               {
                    return collection.Count > MinLength
                         && collection.Count <= MaxLength;
               }
           }
           return false;
     }
}

Conclusion:
The idea behind this pattern is separate things in a very thread safe sort of way, also to unify the context being used as well remain highly testable. In addition, we want to reduce dependencies and the use of reflection. Reflection is an expensive operation that we don't want to do more then we have to. By using DefaultControllerFactory we are able to rely on what already exists. This action alone reduces the amount of foreign dependencies (interfaces, base classes) we need to get our code to work. We have two assets that are used for this purpose IEntity and BaseController.

The next piece to this is how to structure the controllers themselves and how to get the data from the DTOs to the Views in a structured way such that type safety is preserved and we refrain from duplicating as much as possible. That post will follow early next week.

Reflecting on my first tour of duty in New York

2009-10-30T17:46:00.001-07:00

So as I lay here in a hotel in Queens, New York I have had a chance to reflect a little on the experience I have gained over the last few months as I worked for the client out on Long Island. There were many high points and a few low points, mistakes made and successes gained. All in all, I really couldn’t have asked for things to have gone better. I wanted to take some time and share with you some of the the things I learned and/or experienced.

1) The virtues of planning
As a programmer we often hear the stories about staying out late or working long hours to finish a project. I can recall many people in college pulling all nighters to finish projects and the constant stream of rumors from the West Coast that programmers out there often sleep at the office. I have never been a fan of such a thing and usually feel that when you find yourself in such a situation it is most often because you did not plan accordingly.

With this project, I made every attempt to plan. I planned what I was going to do, I planned what I was going to concentrate and think about for the future. I thought about what I would train my colleagues on for a given day. And in the end it really paid off, I worked very little hours and accomplished a great deal. The application that was built was built in accordance with known practices. In fact, a colleague was sent to a Microsoft technology seminar where practices for developing an application was discussed. Upon his return he shared with us what we learned, and essentially described the application’s architecture as I had intended it. This was all thanks to proper planning as well as the invaluable lessons I learned from working with a host of people at RCM.

2) Communication is vital and can be redundant
I have always had a hard time remembering things, so I write stuff down. But when I write stuff down I become too detailed and I miss stuff being said as I am writing stuff down. Thus I am a person who likes to try to understand small detailed chunks and maintain a high level conceptual understanding of what I am doing. I am also not someone who can understand everything via reading, I am very kinetic learner. Thus sometimes I had to ask questions repeatedly to make sure I understood things, especially when it came to the sometimes complex business rules of my client.

To help with this I created a great working relationship with all of the members of the team by being myself. By the end, I felt like one of the members in the company, not a consultant and I was able to speak candidly around them, always maintaining who was in charge. There were times I had to take charge of a situation and explain what can and cannot be done on the fly. I remember once that I had to explain that adding values to a table was great but unless the application knew what the value mean’t you could not add functionality this way, at least with the architecture that was put into place.

I owe this great level of communication to the high satisfaction the client has with what was produced and what they learned from this experience. At the start of the project a couple people knew some .NET others had only ever done AS400 programming. By the end today, they were able to speak about various abstract concepts that they had come across in their own research or things that I had spoke about during training. And they were able to understand why I had made the decisions that I had and how to help each other continue with the design concepts already in place.

3) Dont accept tools and frameworks blindly
If you read and follow this blog you know that we decided to use the Coolite UI framework for this project. Coolite is an set of controls built around the ExtJS framework that is designed to help developers quickly create a rich and visually appealing websites quickly. With the lack of a designer on the team this framework was very appealing and was chosen as the backbone for the application; this was all before I arrived on the scene.

Initially, people were ready to go with MVC and Linq2Sql so we started down that path. But I quickly noticed that this application was going to be complicated and require an advanced architecture to support the requirements. I have no doubt that such an architecture is possible in MVC and I would really loved to have done this application in MVC. However, given that I have far more experience with Webforms and Coolite worked better with the event model offered by Webforms I convinced the client switch to Webforms. While I also tried to convince them to move away from Linq2Sql in favor of the the Kinetic Framework, which we have used at EIS for numerous large web projects.

In the end, because the application was designed so modularly it really could support a change in ORM without a major change, but the reason that was given to me was since the client wanted to use SQL stored procedures for the operations Linq2Sql seemed the best choice to them, so I lost that argument. However, by the end I spoke with the client again about this decision, and he agreed that given the chance he would have revised his decisions and decided to use Linq in place of the stored procedures.

All in all the experience was exceptionally positive for both myself and the client. The application that was created was visually appealing and rich in functionality, and all through the QA sessions very few bugs were found and no critical bugs. Of course, as the application moves to the official QA team I expect that problems will be found but with the excellent communication regarding project requirements I feel that these problems will not be serious. In addition, I was able to impress upon those I was training the value of not just .NET and its languages, but also the value and ability to think abstractly enough to work in a object oriented environment. I look forward to my return in two weeks to assist the client with a second .NET project while the approval for phase two of the current project is decided.

Experiments with ASP .NET MVC Model Binding

2009-10-25T20:05:00.001-07:00

I am really becoming a fan of the ASP .NET MVC framework, it has a lot of flexibility and lends itself well to design patterns that I currently use. I also like the emerging MVVm pattern that has really become widely used among RIA apps. It functions well with MVC and SilverLight because it gives us the flexibility to use ORMs like Entity Framework and Linq2Sql without having to battle with the lost context problem.

I decided this weekend to sit down with MVC and play around with a feature that I really dig: Model Binding. For the uninitiated, model binding in MVC offers developers a way to specify an entity as the argument to a function and based on data sent over via the request create the object for you. The out of the box binder works great and will cover the vast majority of cases. I decided to take this one step further and I wanted to be able to totally bind up my proxy classes (essentially the ViewModels) without having throw away properties that were just used for this purpose and without creating an inheritance hierarchy to allow subclass proxy objects to be used for the binding, offering essentially the same thing as option 1. I wanted this to all happen inside the model binder, so it would be totally transparent.

My result was pretty good, but not perfect. It relies on a dependency and therefore is not 100% transparent and standalone. This is because of what we are doing, we need to abstract the set of the property we need, this could be done via an enforced rule that constructors for proxy entities must follow or have you entities inherit from a common interfaces to guarantee that you have such a setter. I choose to go with the later and defined IEntity as such:

public interface IEntity
{
     int ID { get; set; }
     string Name { get; set; }
}

For our example, the Name setter will not be used, but it is there because it really makes sense that an Entity should provide a name for its object.

So very briefly, the view model pattern relies on the creation of entity classes which are translated from generated entities. This ensures that extraneous information is not passed to the client which can happen frequently when you use generated code in an all-or-nothing scenario. Furthermore, you can reuse these objects within each other and thus gain higher amounts of code reuse which usually translates to greater maintainability. In this example we are going to be focusing on my SeriesEntity class, defined as such:

public class SeriesEntity : IEntity
{
     // simple data references
     public int SeriesId { get; set; }
     public string Name { get; set; }
     public bool IsActive { get; set; }

     // complex data references
     public IList<SeasonEntity> Seasons { get; set; }
     public IList<GenreEntity> Genres { get; set; }
     public StudioEntity Studio { get; set; }
     
     #region IEntity Members
     public int ID
     {
          get
          {
               return SeriesId;
          }
          set
          {
               SeriesId = value;
          }
     }
     #endregion
}

The use of IList here is crucial to the solution I am going to propose, though you could make this any collection type, with the exception of an array.

One of the really neat things about MVC is that in addition to allowing you the ability to override the default binder, you can also specify a binder of a specific type, all you need to is define the binders dictionary in Global.asax.

protected void Application_Start()
{
     RegisterRoutes(RouteTable.Routes);
     RegisterModelBinders(ModelBinders.Binders);
}

private void RegisterModelBinders(
     ModelBinderDictionary binderDictionary)
{
     binderDictionary.DefaultBinder =
          new Binders.AnimeModelBinder();
     binderDictionary.Add(
          typeof(SeriesEntity), new SeriesModelBinder());
}

I am showing this as an example of what you can do with the binding at a type level. We will be using the the DefaultModelBinder base class, so lets start with that class, firstly it must inherit from DefaultModelBinder. This class provides a variety of virtual methods that you can override, the first one we will look at is BindProperty, this is my implementation:

protected override void BindProperty(

     ControllerContext controllerContext,

     ModelBindingContext bindingContext,

     PropertyDescriptor propertyDescriptor)

     // need name of the property we are trying to bind

     var propertyName = propertyDescriptor.Name;

     // find the property on the object we are binding

     var property = bindingContext.Model.GetType()

          .GetProperty(propertyName);

     if (property != null)

          property.SetValue(bindingContext.Model,

          GetObjectValueFromProperty(property,

               bindingContext.ValueProvider[propertyName]),

               null);

The BindProperty method is called each time a new property is discovered that could potentially be binded to. You can control this action by specifying Exclude when defining the parameter list for your action, example:

public ActionResult Create([Bind(Exclude = "SeriesId,Seasons")]SeriesEntity series)

Notice the use of Exclude here, which ensures that the binder will not get SeriesId and Seasons to bind. While our binder can handle it not being there, the lessens the load on the binder.

So lets understand the Binder, first we make a call into GetObjectValueFromProperty function which essentially determines if we need to do anything special with the values, if we dont we make a call to Convert.ChangeType:

return Convert.ChangeType(result.AttemptedValue, property.PropertyType);

I love this method, as it calls the underlying parsing logic to convert the value from (in this case) a string to whatever I desire. It will fail, of course, if the value is not as expected, but this would happen with the normal binder as well. So at this point, we can handle simple one-to-one arguments for value types now. Lets add a means to work with complex objects.

At this point we need to introduce a dependency within our code, that is we need a way to construct our proxy entities and since these are generally custom based on the application, this is where IEntity comes into play. Thus we create a method to generate an instance of a type that, using IEntity, we can set a value to:

private object GetInstanceWithId(int entityId, Type type)
{
     var constructor = type.GetConstructor(new Type[] { });
     var value = constructor.Invoke(null);

     ((IEntity) value).ID = entityId;
     return value;
}

Looking at this code there is one flaw and one major area of improvement. The first one is this casting is unsafe, we have no idea if we can convert the type passed to IEntity and we are hardcoding IEntity rather then letting it being provided. This is not that big of a deal as this is not code most developers working with this binder would ever see, but it is a hard dependency. The best way to check this is before we call the function, we validate the the property type CAN be cast to IEntity, example:

private bool CanConvertToType(Type type, Type conversionType)
{
     var interfaces = type.GetInterfaces();
     return interfaces.Length > 0 &&
          interfaces.Select(t => t.Name)
               .Contains(conversionType.Name);
}

Simply pass the type of the property and the a type reference to the type we want to check the cast for and this method will tell you, though it only works for interfaces.

The final pieces to this is binding a collection of values. One of the things we can do with HTML is send a comma delimited list of values from the view by naming controls with the same name. This will form the basis for our collection binding. The reason we use IList for our entities is so we can perform the binding and as I came to find, creating generic arrays is something .NET does not allow. So the first step is to determine if the property we are looking at IS in fact a collection, we can reuse our CanConvertToType function and pass typeof(ICollection<>) as the conversionType parameter.

The next step is determining the actual type being held by the collection, so we can determine if we can make objects that can be stored in this collection. We can make a simple call to get this information:

Type elementType = property.PropertyType.GetGenericArguments()[0];

Because this is a generic, there will always be at least one argument, and because its an IList we know that the first argument is the contained type. Once we confirm that this type can be used with IEntity we can break apart incoming value and create the IList reference we are going to return. These two lines handle these tasks:

var valueArray = result.AttemptedValue.Split(',');
var valueList = (IList)Activator.CreateInstance(
     (typeof(List<>).MakeGenericType(elementType)));

This code is fairly self explanation, but to reiterate, create a string array from the values coming from the form submit, and use the Activator class to create an instance of List<> that we then cast to an IList.

Finally, we iterate over the string array, and call our GetInstanceWithId function to generate an instance of the underlying type with the ID property set via the abstraction provided by IEntity.

So there you have it, with some very clean reflection we can build an entire proxy entity via the custom model binder, this sets us up for validation and then actions within the controller method. This also centralizes how we set the values for our objects helping with maintainability. Finally, if the case arises that a totally different binder is needed for a certain type, MVC does allow type level model binding configuration which allows MVC to use a certain binder for a certain type. I wonder if you can specify a interface type thus you can declare an model binder for a set of entities.

I hope to add validation to this example for the next entry.

The MVVM pattern and some developer reflection

2009-10-18T14:28:00.001-07:00

It is not uncommon in the world of web programming to see a new acronym floating around every other week. I saw MVVM for the first time a few months ago, but I put off really learning what it was, I was focused on other things and since all the conversation pertained to its use with SilverLight and I was not focused on SilverLight at the time I put it on the list of things to look at.

Then I attended the ASP .NET MVC FireStarter in New York city where they talked about the ViewModel pattern being used for MVC applications. I immediately saw the benefits of this pattern with respect to Microsoft Entity Framework as it took the hassle out of the lost/unloaded context problem I had to circumvent whenever using the framework. I was able to fully create a set of objects that translated the generated entities into classes that could be efficiently used by the View, in addition, I found added benefits from having these classes inherit from each other. And since every OO programmer is continually striving for a way to reuse as much as possible without creating too much complexity, this was a win in my opinion.

What I did not realize at the time was, this is the essence of the MVVM pattern that has been gaining popularity. It happened recently when I was thinking about the application I am developing for the client out here in New York. I realized that in fact I had architected the application to follow this pattern without even realizing it. As is the case whenever you realize such a thing, you start wanting to refactor bits that you did not design according to the pattern, without taking too much time in doing so. I have a number of cases that I am correcting where we are using anonymous objects where we could be using these “proxy” objects as I call them, but they really are ViewModels, I am even starting to create facades for other objects that are composites of other properties within the object.

What I did was I had Linq2Sql generate a bunch of classes based on the tables we are using, each of these classes is proceeded by either a t (table) or a vw (view). The ActiveRecord pattern is used to make these calls into the model, thereby creating a clean separation that allows data access calls to be refactored without changing calling code. At the start, we were returning the data from these calls to the View via anonymous objects. (reasons for using this architecture where mostly due to using the Coolite ExtJs ASP .NET UI Framework). However, as we began to develop the controllers which handled the brunt of the more involved functionality, I began creating classes for use by these controllers. It became almost instantly apparent that these classes could also be used in the Read calls. And now, I am rewriting old code to use objects themselves. The value of this was recently demonstrated when the client asked for a formatting change that required a minimal to change, but the effect was application wide.

The one thing I would like to do differently next time, is make the static methods use to call into the model hang off the view model objects instead, this way there is no visible usage of the generated model classes, this is how my current personal application is setup, though it uses a service based pattern for data access, this is the recommended approach when using a context driven ORM as is the case with Linq2Sql or EF. I have handled the cases in which I want to share my context across many functions (for transacted scenarios) by creating internal functions that can accept an existing context as a parameter, though it is only visible within the assembly it is defined in, this keeps calls in the view from being able to see these functions, thereby hiding the use of a context reference entirely from the view.

The idea of taking the static methods off the generated views and onto the view models themselves is that, like the service pattern, the translation is shared and not implemented all over the place. This means that if you want to change a property that needs to come back, you do it in one spot. For custom queries, you can still define the custom translation in a custom view model. But the point is that you can better control over your translation which helps with maintenance and code cleanliness. One of the ways I am doing this now is creating constructors that build the ViewModel objects for me. But if I can find the time to perform this refactor, it is something I will do. The other concern is that I am training other developers to develop this application, so I need to be careful changing patterns on them.

Experiments with MVC 2

2009-10-11T19:49:00.001-07:00

This weekend I once again sat down to work with my existing MVC application and see what I could find and how I could better improve the pattern and my overall understanding of the framework. I found a few gotchas and came up with some tips to help improve development.

Unit Testing

I was disappointed to find that as of right now, due to breaking changes, updated unit test project templates will be needed to use your favorite unit testing framework with MVC 2. This includes my favorite MbUnit v3. This does not mean that you cannot use the framework, you will just have to do the setup manually.

Validation

One of the things that I am most excited for moving forward is the new way to define validations on the server side. Using the DataAnnotations library, located curiously in the System.ComponentModel parent namespace, you can easily define many of the most common validation routines, from Required to Range. This validation ties tightly in with the MVC framework
One of the downsides to this, however, is that it does not generate client side validation via JavaScript. Thus requests must always be validated on the server, which can be expensive for a busy site.
In addition, you cannot validate complex types (objects, arrays, etc) via this method. I tried with an array that was assigned via ModelBinding, and the validation routine is not even called. However, based on what I read regarding .NET 4, this functionality will be available via the CustomValidator attribute. I really must comment on how it is strange that you can define your own custom validation attribute, but if it is attached to a complex type, you get nothing.

That all aside, I am really impressed with how well this ViewModel pattern works with a deferred execution system like Entity Framework. Since my EF entities never cross into the web layer, only their “dumb” proxy counterparts, the separation is really very clean and easy to maintain. At this point the main problem is the distinct Contexts that are open each session, but I plan to address that next week with Ninject.

The MVC View Model pattern

2009-10-07T18:19:00.000-07:00

Microsoft ASP .NET MVC Framework is Microsoft’s implementation of the popular MVC pattern which was made popular for web applications chiefly by Ruby on Rails. The purpose of the framework is to give developers a choice over using ASP .NET webforms which, until the advent of the MVC framework, had been the only way to develop a web application with ASP .NET.

As with any new framework, especially the web, having a pattern for doing this is essential. Without a pattern developing an application that is clean and a codebase that properly leverages reusability of code in very difficult to do. One of the popular patterns for MVC is the ViewModel pattern. In this entry I will talk about developing an application that users this pattern and also explain why we make the decisions we do in developing the application so that we follow this pattern:

In the project I developed I created a web project to house my MVC project which has the following folder structure:

As you can see I have mutated the default project and removed the Models folder and replaced it with the ViewModels folder. In this folder are the classes that I will be passing to my strongly typed views.

I have created two other projects for this solution that are both class libraries: AM.DataAccess and AM.Models.

This pattern follows some of the advice that I got from @sbohlen at the ASP .NET MVC Firestarter I attended on 10/3. His advice was that it is ok to use an ORM like the ADO .NET Entity Framework to generate your entities but you should not pass them to the View. The reason for this makes sense because the generated entities come with a lot of “extra” functionality. This extra functionality is great in data access scenarios, but really do not make sense in the view.

This is why the ADO .NET Entities are in their own separate project. The Service classes in the DataAccess project are responsible for the translation of these generated entities to the entities that will be used by the view models.

Below is an example of this translation:

This is simply a query that talks to the database via the EntityContext and takes the results and makes a List of these SeriesEntity objects. This list is then passed to my Controller. Once the controller receives it it then creates the necessary ViewModel class to be passed to the View, this is an example of such a piece of code:

The advantages of this model is the isolation of the generated entities with the entities designed for the web. This can reduce the amount of data sent across the wire and decreasing load size. In addition, there entities are more readily serialized into JSON results by MVC. The key thing to keep in mind is the separation of the Web from the Model layer, the two should never cross.

However, a disadvantage with using the Entity Framework in this way is the management of the context object (EntityContext in the example code). The way I have this setup is a lazy loaded property in a base class. The base class also has a destructor which disposes of the EntityContext. It doesn’t permit the sharing of the context by the request. This means you have as many EntityContext references as the number of Service instances that you have. Generally the best way to handle this problem is to use something like StrucutreMap or Ninject for Dependency Injection, however, that conversation is outside the scope of this post.

The main goal of this pattern is to provide a very clean and lightweight means to get data from a database and pass it to the view while maintaining type safety and leveraging code reuse. For example, the ViewModel classes can inherit from each other, like such. First this is the base class for all the ViewModel classes that are in use within this application:

So this base class defines a couple properties that will be in use on just about every page. (Side note: The validation in use here is called FluentValidation). Now lets look at the next level, the SeriesViewModel class:

So this defines all the information we need for the Details view. Now we can use this ViewModel and inherit from it to provide the view with additional information for say the Edit/Create view.

(Note: CheckboxItem is a custom class that I created) Notice what we have available to us now in the View. We have two properties that can tie into existing MVC HtmlHelper methods to provide us with select boxes or a set of Checkboxes.

In conclusion, the ViewModel pattern is a very popular pattern among MVC developers because it reduces clutter in the controller and views, which is what the essence of MVC is: reduction of code and simplification of responsibilities. Furthermore, using ViewModel allows you to share and reuse code across multiple view and can truly make your View agnostic from the controller. This was one of the main weaknesses of the MVP pattern used by ASP .NET, the controller (code behind) was very tightly tied to the ASPX view.

My Trip to the New York ASP .NET MVC Firestarter

2009-10-03T16:31:00.001-07:00

Being in New York has its many perks, one is the awesome big city an hour train ride away. This city and its surrounding area offer one of the biggest markets for technology in the world and it is no surprise that Microsoft has a tremendous presence here. I was informed of this event by my colleague here in New York, Anis. Upon seeing it I immediately registered, not just for its content, but also its location: At the Grand Hyatt in New York City next to Grand Central station. Any excuse I can find to go into the city is a valid one in my book.

I want to thank Peter Laudati, Stephen Bohlen, and Sara Chipps for taking the time to put on this wonderful event, while a lot of the information for me was review, it was still very helpful to get other people’s perspective on the technology as well as meet local members of the New York technology community.

I really enjoyed this session because it got me into thinking mode and finally got a design pattern to click in my head for MVC, I have to thank Stephen for this as he pointed out something that I was doing which I see now is a bit of an overstep in terms of the responsibility of the control. I assumed that I should use EF or L2SQL entity classes as the models that are passed to my strongly typed views. Stephen pointed out that why should I pass these objects, which contain so much extra information, to the model. Make simple versions, he said, and passed those.

At first I didn’t agree with this point as I thought it would lead to class clutter. But as I started to think about it I realized this is already what I am doing on the project out here in New York, where we use Linq2Sql unfortunately. When you look at the application the L2SQL entity NEVER leave the Model layer except as an anonymous object or as a simplified entity object (realizing this made me recognize some areas that should be refactored starting Monday). By using this approach with MVC we can open the ability to TRUELY leverage the idea of the Universal Model. Where a single View can be used by n controllers to display data.

Think about a maintenance screen for satellite data. Generally you just have a Name field and then your normal Create or Update logic. You could design a Web level model class with an interface that has the desired methods on it and simply work with that in the View passing it off as necessary without ever know what you are actually working with. In turn this would use just one view, and save you the headache of many satellite maintenance screens.

That aside, the majority of what was discussed was review, though the conversations were interesting and I was able to get to know a few of the local technologists. Thinking I may look into visiting the New York .NET User group.

Understanding Coolite ComboBox Mode

2009-09-20T12:00:00.000-07:00

This week I came across a very valuable piece of information concerning Coolite combo boxes. A combobox has attribute called Mode. What this is set to greatly affects the overall behavior of the control, and can create extra queries where you may not expect them. I find that having an understanding of this attribute can help you develop more efficient pages using the Coolite ComboBox.

Default – The default behavior for this control is based on how it initially receives its data. If it is connected to a Store of any kind, it will act according to the rules of Remote if no store is provided it will act according to the rules of Local
Remote – whenever the dropdown is expanded make a query to the data store to get the latest data and bind the data according to the DisplayField and ValueField. This is where the second query comes in. Even setting AutoLoad to true on the Store will cause this to happen. Be wary of this second query, especially if the query to get the data is heavy, this could easily create a bottleneck
Local – once the data is loaded do not go out and get new data unless load is called on the Store. This has the greatest chance of working with potentially stale data (depending on your model) but is also the most efficient as it allows you to control when loads happen. Remember, you can easily tell your Store to load by calling the load() method on the store via JavaScript

So what is the best approach, well as my college mentor Dr. George Nezlek used to say “it depends”. I would say for the majority of these calls you are better off explicitly defining the the Mode as Local and controlling the loading of the store through JavaScript and event handlers. However, if the user is going to spend a lot of time on the page and the data is critical and very likely to change, Remote may be the better option.

I would assume there is a way to define poll time for the DropDown query, however, I have not explored that, but something I would look at for the later case.

Hope this was helpful, I discovered this and, as usual, found no documentation from Coolite explaining this, so I thought it would be useful to talk about it here.

Experiments with RIA Services

2009-09-16T12:00:00.000-07:00

Unfortunately I have been so busy as of late I have not had the time I would like to dedicate to exploring the .NET RIA services. I have been quite impressed from what I have seen on video and heard from colleagues (one colleague is already planning to use it in an enterprise project he is writing).

This weekend I decided to sit down and at least understand the mechanics of transmitting data to and from the server and how to extend existing classes to increase functionality. What I found is that RIA Services have a bit of a learning curve while you get your head around the model, but once you do, it works very nicely. My plan was to demonstrate basic binding with an entity generated by the Entity Framework, then move on to include a single related entity, then finally a Many to Many relationships. To start I brought in 4 classes from my AnimeManager database. As expected EF picked up the Many-to-Many and hide the relational table, leaving me with the following:

Let me state that THIS DOES NOT WORK!! The RIA services DO NOT support a many to many relationship defined this way. It took me a bit of scouring but I finally came across this blog entry which explains things: Creating Apps with RIA Services (part 3)

Essentially the key is HOW you add the entities, because you WANT the relational tables. So in this case I deleted the existing EDMX and added this as follows:

Added Studios, Series, SeriesGenres
Allowed the generation of the models
Used Update Model from Database to add the Genres table
Removed the generated relationship between Genres and Series
Recreated this relationship manually by relating Genres to SeriesGenres via this dialog
IMPORTANT!!!! THE NAME OF THE RELATIONSHIP MUST MATCH THE FOREIGN KEY NAME FROM THE DATABASE
After adding this you will set get an error about Association type, use Mapping Details to ensure that this relationships maps to your Many type (SeriesGenres in this case)
Build, everything should go through without fail, once it does you can proceed to the next portion, creating the domain service.

RIA Services creates Services that handle the interaction between the underlying WCF web services and the data extracted via the model layer. To create this access the Add New Item dialog and select Domain Service Class

The following dialog is subsequently displayed:

A service class can support multiple entities, though convention generally dictates that each service represent one entity. For the sake of this I am going to have all three, you will see why in a moment, it has to do with the many to many relationship.

The important thing here is that you click "”Generate associated classes for metadata”.

Following this screen VS will update your solution and add two files: SeriesServices.cs and SeriesService.metadata.cs. It is alright to modify these files as they are only generated once.

By using the SilverLight Business Application template, there is something else going on behind the scenes. VS is looking for these metadata files and is using them to project your classes out to your SilverLight application so they can be used transparently there, with the same namespace I might add. I find it helpful to include this generated file in the solution, otherwise your code looks like its broken until you compile:

Notice the file AnimeManager6.Web.g.cs, this is a generated file which contains a representation of the classes in Silverlight. The one key thing to remember is that your service class (SeriesService in this case) will get generated as a context class instead (SeriesContext in this case). So the code to bind a datagrid would look something like this:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
     SeriesContext sc = new SeriesContext();
     sc.Load(sc.GetSeriesQuery());
     myDataGrid.ItemsSource = sc.Series;
}

Note that while this doesn’t appear as such, this is an asynchronous call. You will find the definition of GetSeriesQuery as GetSeries in your SeriesService method as it is auto generated. The result is returned, in this case, the Series property of the context, if it where a list of a different type it would likely go there. This means that attempting to step through this in real time is useless, more often then note you will get an empty set from Series.

As this object is right now, attempting to bind to either our Studio reference or Genres collection would not yield anything. You have to include these data points via the Include when you query the context, and in the case of Studio, mark it with the Include attribute to get VS to project it to the SilverLight class representations.

So lets first take care of the Studio reference, open up your metadata file and add the [Include] attribute to the reference:

You will note that we are also applying it to the SeriesGenres property, more on this in one second. With this change in place, update your XAML to look for the Studio navigation property and access its Name property: ie {Binding Studio.Name}

Now this is all good and fine and you may be thinking about extending the projected version of Series in the SilverLight project to include custom properties; don’t, this doesn’t work. I am not entirely sure why, but I will show you how to extend the class and in my mind its a better way anyway.

The best way to add these custom properties is by extending the generated models themselves. In this case, this is the code I used to create a property for Series which lists out its Genres in a comma delimited list:

public partial class Series
{
    [DataMember]
    public string GenreDisplay
    {
        get
        {
            if (SeriesGenres.Count > 0)
            {
                var sb = new StringBuilder();
                foreach (var genre in SeriesGenres)
                {
                    sb.Append(genre.Genre.Name);
                    sb.Append(", ");
                }

                return sb.ToString().Substring(0, sb.ToString().Length - 2);
            }

            return "No Genres";
        }
    }
}

The key thing here is the [DataMember] attribute, which causes it to be included in the serialization down to the client. By doing this, it is automatically available to use in the XAML. Bare in mind that as this being done purely on the server before the object is sent down, it is ONLY reliant on either the EntityContext being open or Include being used when making the query. It doesn’t not require the objects themselves to use the [Include] attribute.

This gives you flexibility in the design of the class. It is my opinion, that the generated code is sealed for a reason and modifying the metadata file is likely not a good idea, as this may be something you want to regenerate over time. However, the other effect of using the [DataMember] attribute will cause VS to project the property out to the SilverLight project automatically.

I hope this helps out, getting this information took me some time and drove me nuts in getting it to work.

Performing ASP .NET Submits with Coolite Form Panel Events

2009-09-09T13:33:00.000-07:00

As with anything in programming there are a number of ways to do any operation, sending data to server side code in Coolite is no exception. One of the ways that I have found very useful is via the OnEvent configuration for an AjaxEvent.

To begin with one needs to understand that a FormPanel is not a representation of the <form> tag from HTML, but rather similar to the UpdatePanel control from ASP .NET Ajax. AjaxEvents are then like triggers. However, since this trigger could reside anywhere on the page we need a way to “link” the panel viewstate to the trigger so the ViewState is transmitted and we get the desired information that we need. This is done via the FormID attribute on both the AjaxEvent and the FormPanel. In addition, fields that are to be transmitted seem to require a Layout, meaning they cannot simply be placed adhoc on the page. Thus the initial HTML fragment looks something like this:

<ext:FormPanel ID="fpMain" runat="server" FormID="mainForm"
    ButtonAlign="Right" Title="My Form">
    <Body>
    </Body>
</ext:FormPanel>

I am only defining a few of the essential properties here. As I said earlier, FormID helps Coolite identify which ViewState set to submit as part of the AjaxEvent. All Panels in Coolite have a section dedicated for buttons, we can use the ButtonAlign property align those buttons as we wish.

For the next segment I will define a could fields using the FormLayout control. Understand that this Layout in particular has a lot of extra functionality and uses, I am not going to show case all of them here. I will talk about it later on, for now I would advise visiting http://examples.coolite.com and looking under the ‘Layouts’ section.

<ext:FormPanel ID="fpMain" runat="server" FormID="mainForm"

    ButtonAlign="Right" Title="My Form">

    <Body>

        <ext:FormLayout runat="server" LabelSeparator=":"

            LabelAlign="Left">

            <ext:Anchor Horizontal="95%">

                 <ext:TextField ID="txtName" runat="server"

                     FieldLabel="Name" />

            </ext:Anchor>

            <ext:Anchor Horizontal="95%">

                 <ext:NumberField ID="nbrAge" runat="server"

                    FieldLabel="Age" MaxLength="3" />

            </ext:Anchor>

        </ext:FormLayout>

    </Body>

    <Buttons>

        <ext:Button ID="btnSubmit" runat="server" Text="Submit"

            Icon="Accept">

            <AjaxEvents>

                <Click OnEvent="btnSubmit_Click" FormID="mainForm">

                    <EventMask ShowMask="true" Msg="Submitting Data"

                        CustomTarget="fpMain" Target="CustomTarget" />

                </Click>

            </AjaxEvents>

        </ext:Button>

    </Buttons>

</ext:FormPanel>

So I have defined here two form fields within FormLayout one holds a normal textfield and the other a numbers only field. To finish this implementation we need to define the btnSubmit_Click event handler in the code behind file. The implementation I will use is:

protected void btnSubmit_Click(object sender, AjaxEventArgs ev)
{
    Ext.Msg.Alert("Alert",
        string.Format("Welcome {0} (Age {1}). Today is {2:d}",
            txtName.Text, nbrAge.Text, DateTime.Now))
    .Show();
}

Admitting, this is a very simple concept of what a server side event could do; it simply shows a Coolite style modal that is designed to substitute the standard JavaScript alert window. Here we are basically telling the user the information they entered as well as attaching a server side piece of data (the current date). You can image business logic being here for adding this data to a persistent store, such as a database. I will save another blog entry to talk about validating this data since Coolite can take care of a great deal of that for you.

One other interesting thing to note, and is something that I have observed. When you start getting into these sorts of scenarios where you are using these events, you will want to be conscious of the fact that even though Coolite states the <form runat=”server”> tag is not needed in the little docs they have, this is false. You will find this very true when you start trying to submit changes to a grid or pick up what rows of a grid where selected. I will have an example of this next.

The key thing here is to understand the connection between FormPanel and how to send data from the client to the server is a way that is more familiar to ASP .NET web programmers. Remember to mindful of the view state you are including and you can always validate things are working by checking the state of form fields on the server, I still do this at the onset, just to be sure I know what I am submitting.

Using .NET Extension Methods for Type Conversion Libraries

2009-09-07T09:58:00.000-07:00

One of my favorite features in Microsoft .NET is extension methods, primarily because of the clean syntax they provide for formatting and perform special operations against types. I never really never did like static helper methods like this:

DecimalHelper.FormatAsMoney(decimalValue);

I just felt that this was not clean and felt more procedural then it should in an object oriented language like .NET. Nonetheless, it satisfied the need of being able to centralize logic for dealing with certain common conditions, least of all Type conversion (ala the Convert class). With the advent of the LINQ syntax in .NET 3.5 Microsoft provided support for using extension methods. These superficially attached methods are my favorite feature in .NET as they are able to achieve the same result as the helper methods above, except with a much cleaner syntax in my opinion:

decimalVaue.AsMoney();

So I started thinking, this would be very useful for creating “smart parsers” for converting types, in particular strings to various data types, a common and often tedious exercise in web applications. Smart parsers encapsulate the calls to TryParse and allow the method call to return a standard value on fail or, with an overload, return a default value. This is an example of my AsInt smart parser function:

public static int AsInt(this string s)
{
    int d;
    return !int.TryParse(s, out d)
        ? int.MinValue : d;
}

public static int AsInt(this string s, int defValue)
{
    int d = s.AsInt();
    return d == int.MinValue
        ? defValue : d;
}

I always did hate calls to Convert and TryParse cause I felt the code was dirty and parsing in general sometimes needs to aware of Globalization settings. As a result of the success I have had using this on many enterprise projects, I have made it a standard that I implement. I decided recently, at the advisement of a co-worker to publish something. Its not much, but its a few of the standard methods that I work with. A lot of these sort of methods are born out of a need to create consistency in the application, mostly related to formatting.

Below is the link to download what I currently have developed (along with some unit tests). I hope to have this grow into a full fledged type conversion and formatting library.

Grouping with Coolite GridPanel

2009-09-04T17:14:00.001-07:00

One of the nicest things about Coolite is that you can easily get a very modern looking website in short order, provided you take the time to understand the examples and ExtJS documentation, which maps pretty closely to the controls. But there are still little niches you need to know to get the controls to work how you want. One of the most finicky controls, I have found is the GridPanel.

So much interactivity can be achieved these days via JSON and grids it really is breathtaking when you pull it off. Coolite is no exception, in fact, when configured properly, it has one of the must full featured grids I have seen on the web, once you get there that is. I will talk about the grid a lot in posts to come, primarily about databinding, and updating. But today we will focus on grouping.

Grouping is an effect where by a top level is rendered based on data groups, these can be expanded to show the children of that group along with aggregation data. Today I am going to explain how to take a simple array of data and generate a grid panel which supports grouping. To begin, here is some sample data we will feed our grid:

var aList = new List<Order>()

    new Order() { OrderId = 100, ProductId = 3,

        ProductName="Product 3", UnitPrice = 5.00m,

        Quantity = 21 },

    new Order() { OrderId = 100, ProductId = 6,

        ProductName="Product 6", UnitPrice = 1.00m,

        Quantity = 22 },

    new Order() { OrderId = 100, ProductId = 7,

        ProductName="Product 7", UnitPrice = 2.00m,

        Quantity = 23 },

    new Order() { OrderId = 200, ProductId = 3,

        ProductName="Product 3", UnitPrice = 3.00m,

        Quantity = 24 },

    new Order() { OrderId = 300, ProductId = 4,

        ProductName="Product 4", UnitPrice = 4.00m,

        Quantity = 25 },

    new Order() { OrderId = 400, ProductId = 5,

        ProductName="Product 5", UnitPrice = 5.00m,

        Quantity = 26 },

    new Order() { OrderId = 500, ProductId = 8,

        ProductName="Product 8", UnitPrice = 6.00m,

        Quantity = 27 },

    new Order() { OrderId = 500, ProductId = 9,

        ProductName="Product 9", UnitPrice = 7.00m,

        Quantity = 28 },

    new Order() { OrderId = 500, ProductId = 1,

        ProductName="Product 1", UnitPrice = 8.00m,

        Quantity = 29 },

    new Order() { OrderId = 200, ProductId = 2,

        ProductName="Product 2", UnitPrice = 9.00m,

        Quantity = 20 },

    new Order() { OrderId = 700, ProductId = 3,

        ProductName="Product 3", UnitPrice = 1.00m,

        Quantity = 21 },

    new Order() { OrderId = 700, ProductId = 4,

        ProductName="Product 4", UnitPrice = 2.00m,

        Quantity = 22 },

    new Order() { OrderId = 800, ProductId = 4,

        ProductName="Product 4", UnitPrice = 3.00m,

        Quantity = 23 }

};

Ok, maybe that was a bit excessive, but moving on. Coolite emphasis a UI pattern I like to call “late loading”. The basics of this pattern is that the main frame of the page should come in first and then the data. This gives the user the impression of a page load and lightens the load. This technique is commonly employed with data heavy applications which utilize a single page architecture and simply move data (usually in JSON) to and from the server using asynchronous calls.

My favorite way of getting data with Coolite are ASP .NET Generic Handlers (.ashx), mainly because they are extremely lightweight and have some very nice uses with GridPanels. This is the code for the ASHX, notice the use of the NewtonSoft JSON Library (this is included with the Coolite download) to serialize the List into JSON and pass it back, also notice the content type definition, to text/json.

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class DataHandler : IHttpHandler
{
        public void ProcessRequest(HttpContext context)
        {
            List<Order> list = Order.GetData();

            context.Response.ContentType = "text/json";
            StoreResponseData data = new StoreResponseData();
            data.Data = JSON.Serialize(list);
            data.Return();
        }

        public bool IsReusable
        {
            get
            {
                return false;
            }
    }
}

What this will do is return a JSON object to be read by a Coolite ExtJS data store and then bound to a control. In this case, the data that is being returned can easily be grouped by its OrderId property. We can have Coolite take care of most the heavy lifting for us. So we will first define our data store:

   1:  <ext:Store ID="store" runat="server" AutoLoad="true"

   2:      AutoDataBind="true" GroupField="OrderId">

   3:      <Proxy>

   4:          <ext:HttpProxy DisableCaching="true" Json="true"

   5:              Method="GET" Url="/DataHandler.ashx" />

   6:      </Proxy>

   7:      <Reader>

   8:          <ext:JsonReader>

   9:              <Fields>

  10:                  <ext:RecordField Name="OrderId" />

  11:                  <ext:RecordField Name="ProductId" />

  12:                  <ext:RecordField Name="ProductName" />

  13:                  <ext:RecordField Name="UnitPrice" />

  14:                  <ext:RecordField Name="Quantity" />

  15:                  <ext:RecordField Name="Total" />

  16:              </Fields>

  17:          </ext:JsonReader>

  18:      </Reader>

  19:  </ext:Store>

Ok there is a lot here so we will go line by line. First we are defining the Store and saying that we want it to AutoLoad which means a request will be made as the page becomes ready. The key here is the GroupField definition which is what will format the outgoing result in a way that the GridPanel will use a grouping format to output it.

The connections to the data sources are initiated through Proxies. The interesting thing here is that you can also define a WriteProxy to handle changes to Store via the Grids inline editing feature. In this tutorial we are only going to be covering using a ReadProxy:

DisableCaching: This prohibits the browser from caching a request.
Json: This just ensures that what we get back from the request is JSON, I define this just to be explicit with what is coming back
Method: Once again this overloads the default value, and just explicitly states that we wish this request to be carried out over GET
Url: The URL of where to make the request to, in this case we are specifying the URL to our custom ASHX

The next part is the Reader definition; this is defining what the JSON object is going to look like on the client side as it is worked with on the client side. Make sure the values of the Name attributes match their respective property values of on the JSON object coming over. I mistakenly thought this was the order of serialization, but it is not; they match one to one. You can optionally define the Type attribute, but for the most part Coolite will infer the types.

With this defined, we are now ready to move onto defining our GridPanel which will actually provide the UI for the user to see. The definition is rather long, so I will be breaking this apart based on the internal nodes for definition, to start here is the outer structure which has the base property definitions:

<ext:GridPanel ID="gpPanel" runat="server" AutoHeight="true"
    StripeRows="true" StoreID="store" AutoDataBind="true">
</ext:GridPanel>

The important attributes here StoreID (which defines which store this control is associated with), also AutoDataBind which will automatically rebind the grid whenever a change is detected in the associated store. The other attributes are defined for aesthetic purposes.

The next thing to do is to define how the grid will look without Grouping and what columns will be included, to do this we define a ColumnModel node within the GridPanel:

<ColumnModel runat="server">
    <Columns>
        <ext:Column DataIndex="OrderId" />
        <ext:Column DataIndex="ProductName"
            Header="Product" />
        <ext:Column DataIndex="UnitPrice"
            Header="Price">
            <Renderer Format="UsMoney" />
        </ext:Column>
        <ext:Column DataIndex="Quantity"
            Header="Qty" />
        <ext:Column DataIndex="Total">
            <Renderer Format="UsMoney" />
        </ext:Column>
    </Columns>
</ColumnModel>

You notice the DataIndex matches the value of the Name attribute from the JsonReader RecordFields. Understand that the column model defines ONLY what fields from the JSON object you want to display. The row will STILL contain a reference to the whole JSON object, but this way you can choose to hide fields like PKs (We are doing this with ProductId in this case), but they are still usable when a GridCommand is invoked.

Notice also that we are using the built in Render formatting that is provided by Coolite. There are quite a few of them that come out of the box, in addition you can define your own.

So if you run this code right now, you will get a simple grid, but you will still not see any groupings, this is because we need to define a GroupingView node for this GridPanel to see the grouping in action.

<View>
    <ext:GroupingView ID="gvGrouping" runat="server"
        ForceFit="true" HideGroupedColumn="true">
    </ext:GroupingView>
</View>

Views are an extremely vital piece to the GridPanel as they can help you define further configuration in terms of function and formatting. Here we are using the GroupingView which defines how the Grid will look when it is grouping. We define two attributes for aesthetical purposes: ForceFit and HideGroupedColumn. ForceFit merely forces the Grid to fit its entire available width, it tends to make the grid look a lot nicer. HideGroupedColumn hides the column you are grouping on.

Running the code now you will see the GridPanel and your data grouped by the OrderId. The blocks are expandable and collapsible, and their initial state can be defined on the GroupingView. The GridPanel offers an immense amount of functionality and can really help you display your data. It also best demonstrates ExtJs reliance on the “late-load” content loading technique. Your controls will be rendered and the data will be brought in via Store’s that in most cases will be linked to a web service of some kind. This data is then placed into either an Array, JSON, or XML, depending on what you define. In our example, we used JSON. We associated this Store with a Grid via the StoreID attribute of the GridPanel. In addition, we define the Grouping column for the Store, this is what enables our grouping.

Finally, we use a ColumnModel and View to define how the Grid will look under certain situations. Remember that you do not have to define a column for all members of your JSON object, only the ones you want to display, sending a row command will still give you access to all the properties defined on the object via the JSON reader.

Creating Modal Windows with Coolite

2009-08-26T20:00:00.001-07:00

One of the most popular effects in web development, is the modal dialog. Using standard CSS we are able to create the appearance of a modal dialog on a webpage that can be used to provide a quick login form, more information, or any of a thousand other things. Naturally, most UI frameworks have this effect built-in so developers can quickly create this effect without having to worry about cross browser problems; Coolite is no exception.

Generally, the way this is achieved is a <div> is placed somewhere on the page (usually at the bottom) and is targeted with JavaScript which does some fanciness to give it various look-and-feel properties. Coolite is slightly different, but in a way that makes more sense. It leverages the idea of the “viewport” as the main page, that is what the user see’s without the modal. In Coolite we would define this as such:

<ext:ViewPort ID="vp1" runat="server" AutoHeight="true">
    <Body>
    </Body>
</ext:ViewPort>

The basic idea here is that the viewport serves as a wrapper for your main content. So we could define our main UI here, for this example we will simple put a button which opens the modal.

<ext:ViewPort ID="vp1" runat="server" AutoHeight="true">
    <Body>
        <ext:Button ID="btnOpen" runat="server" Text="Open"
            Icon="Application">
            <Listeners>
            </Listeners>
        </ext:Button>
    </Body>
</ext:ViewPort>

Next we define the code for our Modal window, for this example, we are going to constrain the width and put some lipsum text

<ext:Window ID="Window1" runat="server" AutoHeight="true" Width="400" Constrain="true"
    Modal="true" ShowOnLoad="false" ButtonAlign="Right" Title="Modal Window">
    <Body>
        Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum
        has been the industry's standard dummy text ever since the 1500s, when an unknown printer
        took a galley of type and scrambled it to make a type specimen book. It has survived not
        only five centuries, but also the leap into electronic typesetting, remaining essentially
    </Body>
    <Buttons>
        <ext:Button ID="btnClose" runat="server" Text="Close" Icon="Cancel" />
    </Buttons>
</ext:Window>

So this is fairly simple and straightforward. We have defined our main layout in a ViewPort and then we have defined external layout elements (the modal) in Windows that are defined outside the ViewPort. I defined only the essential properties of the modal, but there are quite a few properties, such as X and Y to define the starting location of the modal.

However, we are missing one critical element; with this current code there is no way to show the modal to the user. There are two ways to do this, and your selection of the means to do this will depend on your scenario. You can open this with both JavaScript and the .NET code behind. In JavaScript, we simply add a listener node and listen for the “Click” event. Thus our buttons definition looks like this:

<ext:Button ID="btnOpen" runat="server" Text="Open"
    Icon="Application">
    <Listeners>
        <Click Handler="Window1.show();" />
    </Listeners>
</ext:Button>

This is the approach I like to take for simple calls, just define the Handler property with the JavaScript you want. Its a “do it once and throw it away'”. However, if you’re going to duplicate logic and call it throughout the page, I would then define the Fn property and centralize all that logic in a single function.

In addition, the Window component has many events that you can catch, with JavaScript or Server-side code, though client side will be much easier to understand. I will list out some of the more useful ones that I have used:

BeforeShow – fires just before the modal is shown to the user. Useful as a means of resetting modal content from an pre-existing operation.
BeforeHide – fires just before the modal disappears from the users view
Hide – fires after the modal is closed via a call to hide() on the Window element
Show – fires after the modal is shown to the user

So as I mentioned the same effect can be accomplished using AjaxEvents. To do this you would simply update the Button definition removing the <Listeners> node with the <AjaxEvents> note, like such:

<ext:Button ID="btnOpen" runat="server" Text="Open"
    Icon="Application">
    <AjaxEvents>
        <Click OnEvent="btnOpen_Click">
            <EventMask ShowMask="true"
                Msg="This is a Loading Mask" />
        </Click>
    </AjaxEvents>
</ext:Button>

This defines that for the button the Click event raises an AjaxEvent which is handled by the btnOpen_Click method in the page code behind. From this position you have access to related page elements. What does it mean to be related? I honestly dont know, this is one of the aspects of Coolite that is largely undocumented. From what I can gather, it seems to be the parent container, though you can define a specific form to link to the AjaxEvent, via the FormID attribute.

Notice that we are also defining a mask to be visible when this event is occurring. Remember that we are going back to the server, so it makes sense to give the user some feedback; thus in the event the operation takes time the user is notified and appropriate interactions can be prevented. To give you an idea what the code behind method looks like in this case, here is what btnOpen_Click looks like:

protected void btnOpen_Click(object sender, EventArgs ev)
{
    Window1.Show();
}

Very simple and straightforward. You could imagine having checks in here to prevent the modal from showing if certain conditions were not met, or populating modal elements with server data.

To conclude, the big thing to remember about Coolite modals, is that they must be placed outside a ViewPort component with the Modal property set to true. There a wide variety of properties that you can configure for the window to improve the look and feel of the modal as well as positioning. Modals provide a great way to display related information or provide a drill down into data, they can be used to simplify interfaces and provide more elegant ways to access commonly used functionality, while continuing to move the web application closer to the goal of behaving like a desktop application.

Understanding AjaxEvents in Coolite ASP .NET

2009-08-24T15:00:00.000-07:00

In the first tutorial in this series we created a very basic Hello form that relied on JavaScript for its core. We also saw how easy it was to build a very clean and modern looking form using Coolite. But what are there things called AjaxEvents.

Going to the Coolite website we find that, as with most of Coolite, there is a total lack of documentation as to what AjaxEvents are, although there are samples showing how to use them. Based on these examples I would say they are simple postback requests that can be used to post data to the server.

They are able to “target” a specific form (they default to the form they are in) and send the current state of the items in that form to the ASP .NET code behind where they can be operated on as desired. These requests are then able to fire the events of other controls that have events defined (ex Grid, Store). In addition, you are able to configure an event mask for while the request is in process. This helps the user know that “something is happening”.

So to begin here is a screenshot of code from the first tutorial, but I have cut the JavaScript out and removed the Listeners node from the Button

The first step is to update the Button markup as such:

<Buttons>
  <ext:Button ID="btnSubmit" runat="server"
   Text="Submit" Icon="Accept">
    <AjaxEvents>
      <Click OnEvent="btnSubmit_Click">
      </Click>
    </AjaxEvents>
  </ext:Button>
</Buttons>

Very similar to the <Listeners> node (and in fact these can be combined with a listener, return false, will stop the request), we are saying that “when the Click event occurs, create an AjaxEvent which is handled by the handler btnSubmit_Click in the code behind”. This what our handler could look like:

protected void btnSubmit_Click(object sender,
     AjaxEventArgs ev)
{
     Ext.Msg.Alert("Alert",
         string.Format("Hello {0}", txtName.Text)
     ).Show();
}

Notice that we are using the AjaxEventArgs type for the EventArgs type. This is a special event args that contains a few extra properties that can be of use. Most notably the ExtraParam and ExtraParamnsResponse properties. The former allows you to send this via the Ajax call that may not be contained in controls you can access.

The final piece of this application is the event mask. This is a very simple operation so we dont really need a mask. Masks are very useful to for stopping the user from interacting with the page or parts of the page while an action is in progress. With Coolite these are easily definable and fit well with the application.

First add a call to “Thread.Sleep(1000);” to you handler function so that you will get a chance to see the mask we are doing to define. Return to the Button code and update it as such:

<ext:Button ID="btnSubmit" runat="server"
    Text="Submit" Icon="Accept">
    <AjaxEvents>
        <Click OnEvent="btnSubmit_Click">
            <EventMask Msg="Generating Message" ShowMask="true"
                Target="CustomTarget" CustomTarget="fp1" />
        </Click>
    </AjaxEvents>
</ext:Button>

The two key properties in the <EventMask> tag are ShowMask and Msg. The former states that when this event is active we do want to show the mask. The later defines what message the user will see while the event is in progress. In addition, I have defined the Target as CustomTarget which allows me to specify which section will be grayed out, by default it is the entire page. In this case I am specifying the control with the ID of “fp1” which is the FormPanel all of this is sitting inside of. The end result is when you are waiting for the name to come back, your form should look like this:

To conclude, this article focused on using AjaxEvents with Buttons and how to control the EventMask. Remember that you can do a lot more with AjaxEvents as they can be applied to most any control. You just need to tweak things sometimes and always check your pages that the calls are getting the right state data from the controls. Most of my testing has been with FormPanels and I have found that things not inside FormLayouts are often not submitted for whatever reason.

AjaxEvents are a big reason why I enjoy using Coolite with webforms over MVC; because I can take advantage of events are server side code in C# as opposed to writing more JavaScript. But using these two posts you should understand that your code will not be that different in most cases, regardless of which approach you use.

Getting Started with Coolite on ASP .NET

2009-08-23T08:09:00.001-07:00

I am currently engaged in an opportunity that has taken me to New York to help a client rewrite one of their existing VB6 applications in ASP .NET as a web application. To aid us with developing this application and provide a very modern and consistent look and feel we are using the Coolite UI Framework for ASP .NET which leverages the powerful ExtJS JavaScript library inside of WebForm controls.

However, we have found that the the biggest downside to using Coolite is the intense lack of documentation from the creators. This makes it hard to know exactly what we are doing and often leaves us to pull from two or three sites to fully understand what it is capable of. The biggest help comes from the Examples site, and the ExtJS documentation site, since the controls follow the supported properties for those controls. ExtJS has excellent documentation. But I wanted to talk about Coolite cause I think it has a lot of potential and can really be very helpful if people learn more about it. So to start this series I am going to give a very basic example of an application which uses Coolite and JavaScript. So lets get started.

To begin you will need to download the Coolite binaries from Coolite.com, this will install three binaries (Coolite.Ext.Web.dll, Coolite.Utilities.dll, and Newtonsoft.Json.dll) and reference these in your solution.

The second step is to update your web application web.config file to support Coolite in the application. So first add this line to your web.config after the last section group.

<configSections ..>
  </sectionGroup>
  <section name="coolite"
       type="Coolite.Ext.Web.GlobalConfig"
       requirePermission="false"/>
</configSections>
<coolite idMode="Explicit"
       theme="Default"
       initScriptMode="Linked"
       scriptMode="Debug" />

Also included in this screen shot is the next step of what to add, and that is the new section as defined by the section definition we just added. Here you can specify a number of things, but the two things to take note of here are:

idMode: use Explicit here so that Coolite controls can be referenced in JavaScript without worry about naming containers as with typical ASP .NET controls
theme: defines the UI styles that Coolite will reference for all controls. Can be Default, Gray, Slate

The next thing we have to add are some reference to HTTP handlers and modules; so we add the following lines to the web.config:

To httpHandlers:

<httpHandlers>
  <add path="*/coolite.axd" verb="*"
     type="Coolite.Ext.Web.ResourceManager"
     validate="false"/>
</httpHandlers>

To httpModules:

<httpModules>
    <add name="AjaxRequestModule"
         type="Coolite.Ext.Web.AjaxRequestModule,
                    Coolite.Ext.Web"/>
</httpModules>

Optionally, I like to add the following line to my pages collection in system.web to make referencing the Coolite controls easier:

<pages>
    <controls>
        <add assembly="Coolite.Ext.Web"
            namespace="Coolite.Ext.Web"
            tagPrefix="ext"/>
    </controls>
</pages>

So lets start with building a simple form that will say “Hello {name}” provided a name in a textbox. I am going to do this using JavaScript on the client side, another blog post will detail doing it with AjaxEvents.

So lets first show some basic markup that uses Coolite to create a form, this first thing that every page using Coolite controls must have is a ScriptManager to facilitate the inclusion of JavaScript to support the various effects, so:

Next, we will want to create a small form, so we will use a FormPanel control, which gives us a very nice look and feel, so:

I have defined a lot of properties on the form, here is an explanation for a few of them:

FormID: Used in AjaxEvent referencing and to tie controls to certain actions, not really used in this approach, but will be useful when we show AjaxEvents
Title: The title displayed for the Form (see next screenshot)
ButtonAlign: The alignment of the buttons defined in the FormPanels <Buttons> portion
StyleSpec: The style rule to apply to the panel as a whole

Running this should produce the following UI:

Not a bad looking UI considering we haven’t had to do any CSS and this is compatible with IE6 even, so lets keep moving forward and add the actual UI.

The FormPanel has quite a few internal sections, for this tutorial we will use two of them <Body> and <Buttons>. Here is the updated code:

   1:  <body>

   2:    <ext:ScriptManager ID="ScriptManager1" runat="server" />

   3:    <ext:FormPanel ID="fp1" runat="server"

   4:      FormID="mainForm" Title="Test Form"

   5:      Height="150" Width="300" ButtonAlign="Right"

   6:      BodyStyle="padding: 10px;"

   7:      StyleSpec="margin: 10px;">

   8:      <Body>

   9:        <ext:FormLayout ID="frmLayout" runat="server"

  10:          LabelSeparator=" " LabelAlign="Left">

  11:          <ext:Anchor>

  12:            <ext:TextField ID="txtName" runat="server"

  13:              AllowBlank="false"

  14:              MaxLength="15" FieldLabel="Name" />

  15:          </ext:Anchor>

  16:        </ext:FormLayout>

  17:      </Body>

  18:      <Buttons>

  19:        <ext:Button ID="btnSubmit" runat="server" Text="Submit" Icon="Accept" />

  20:      </Buttons>

  21:    </ext:FormPanel>

  22:  </body>

So what we have done first is the update the body of the FormPanel with a FormLayout. There are a lot of things that FormLayout does for us, but for new its enough that it will render the elements described in each <ext:Anchor> block vertically with some label text to the left.

In this case we are adding a a Ext Textfield that has a few things defined:

AllowBlank – the textbox will validate user input and require input
FieldLabel – this is the text of the label that will appear to the left. It can also appear above the control, this controlled by the LabelAlign property (see the FormLayout)

Next we move to the <Buttons> group. This section is placed beneath the Panel body and houses button controls, here I am defining a single button. If you run this, it should output something like this:

The next part of this is to allow the user to click “Submit” and have the program respond with an Ext alert that says “Hello”. So the first thing we will need is something to listen for this event. Update the Button definitions as such:

<ext:Button ID="btnSubmit" runat="server"
  Text="Submit" Icon="Accept">
  <Listeners>
    <Click Fn="SayHello" />
  </Listeners>
</ext:Button>

There are a number of events that we can listen for, obviously the one that makes the most sense in this case is Click. So when a click happens we want to call the function SayHello. So here is a look at the SayHello function:

<script language="javascript" type="text/javascript">
    var SayHello = function() {
        var name = txtName.getValue();
        Ext.Msg.alert("Alert", "Hello " + name);
      }
    </script>

Notice how we are getting the value of the text field, we are simply calling its name, no ClientID (in this case). We are then creating an ExtJS alert window to display the message. The reason we use this here is that it will provide an alert that is linked to our theme, this way all visual elements have the same appearance. So clicking the button should do this:

One thing I do want to point out is that this alert window is NOT an alert window. It does not block execution, it relies on callbacks to execute code after the “OK” click. It is nothing more than a modal dialog being shown.

So there you have it, that is a very basic application which uses Coolite to perform a very basic function. The next time around we will describe how to do this using AjaxEvents, which are a very interesting concept and take much of the problems you encounter with MS Ajax out of the picture.

Moving from ASP .NET MVC to ASP .NET Webforms

2009-08-15T14:26:00.001-07:00

It is very common to hear developers talk about successfully switching to MVC and generating much cleaner applications and there is no doubt that using MVC can certainly generate that. But as with any technology/framework, misusing it can still result in an application with maintainability issues and the need for the developer to make undesirable decisions.

Such was the case out here in New York where our client had decided to use the MVC framework with the Coolite UI toolset. I am a big believer then when it comes to using the MVC framework one needs to be careful that the toolset you are using also leverages what MVC gives you. In the case of the project out here, after numerous discussions it was clear that really the way we were approaching the project we were just not going to leverage MVC in a way that would make sense to use it. In reality, the project would be better off, given the aims, as a Silverlight project, but due to circumstances surrounding the project it was not an option.

In addition, we had decided to use the Coolite control toolkit for UI. Given the way that Coolite is setup it makes sense to use it with WebForms over MVC. While you can certainly use MVC with Coolite (as demonstrated by http://mvc.coolite.com) after spending a week developing in MVC with Coolite it became apparent that it didn’t make sense and I felt we were heading for some problems. I took these problems to the other developers and after some conversation we decided we needed to talk to the client about possibly changing, let me enumerate some of the arguments that were made:

MVC’s biggest strength is the decoupling of the view from the controller and the lack of reliance on server controls

In our case we are not really using this methodology heavily, instead relying more on web services to talk to the database. This due to the other devices that must be able to tie into this system

Coolite is designed to work with ASP .NET webforms. Using Coolite with MVC means a large reliance on JavaScript to gather values and perform saves.

Using Webforms we can use the code behind to leverage .NET in a way that makes sense given the operations we are performing

With Webforms we can still use web service method calls to get data from our database. It also allows use to make WCF calls via code-behind if needed

The big point that was made here was that we are only talking minimal gain using MVC from a structure standpoint vs. potentially difficult choices in saving and persisting data and leaning very heavily on JavaScript. In addition, if done properly an ASP .NET Webform app can be just as well organized as an MVC application if done correctly. I have certainly see it done by some of the best in the industry and I have their experience to lean on in doing this. I really think this is the best decision, as much as I want to use MVC, I think you just don't gain anything give what we are doing and how we are approaching it.

Repository Pattern (Revisted)

2009-08-01T21:57:00.001-07:00

In the previous tutorial set we looked at the Repository pattern and how one might use it to construct a support framework for Fluent NHibernate. If you looked at closely you likely realized some very serious and obvious design flaws. The main thing that I didn't like about it was the use of the derived repositories and the constraints it placed on various user stories. For example, in order to save related items, or perform read operations, multiple repository instances were needed. This creates a huge burden on the developer. What is really needed in this case is a store, that is a single class that provides lazy loaded instances of the other repositories the system supports.

To begin this process, we first need to generate code. Our types are not known to use at any point until after a database is read. To do this we will use T4 templates. I will blog later on about creating these templates for now we are just working to understand the theory.

So the idea behind this reorganization is to create a single class that all other repositories work off. The repository instances for the specific models will need to provide enough extensibility to let developers take control of the save process, but also provide enough out of the box functionality so that it is useful without modification.

Furthermore, we want to encourage developers to use our single instance so we need to provide a way for their functions to be called in place of our original. To do this we will use abstract base classes with virtual methods. By defining a default save method as virtual in the base class we can provide the developer a way to override the function that is automatically called when a Commit is initiated on the store’s objects.

So the Store is generally in charge of initiating the Commit process via reflection and finding appropriately decorated properties that represent the Repositories. The commit is only called if the list is deemed to be dirty.

Each of the derived repositories can only hold objects of certain type, the type must inherit from EntityBase thereby insuring that the object being operated on is an Entity. Finally the Entity saving, deleting, and updating operations are all handled in a totally database agnostic way by NHibernate under the hood thanks to the mapping generated via Fluent NHibernate.

So the end result of this process is that using T4 templates we are able to generate the POCO (Plain Old C# Objects) model files, the Fluent Mapping files, the Derived Repository definitions and the generated portion of the Store all automatically. In addition, we make all classes partial enabling developers to extend them as they see fit. This gives us a tremendous about of flexibility for developers to customize certain operations. This model for repository is a little more closer to what the pattern fully intends, though really is more of a Store pattern, similar to what Linq to SQL and Linq to Entities appear to use to great effect. In coming tutorials I will back track and help you understand how to create a fully functional Repository Store support framework.

Exploring the Repository Pattern (Part 2)

2009-07-23T13:47:00.000-07:00

In the first portion of this article we explored what the Repository pattern is and provided a basic implementation for now developers are using it to facilitate data access. We create a basic class RepositoryBase<T, PK> and showed a basic example of using it. Now we will explore this class and demonstrate how to take the Repository further and make it more useful.

Now, in what we created there is one major obvious drawback. If we wanted to write a custom query how do we do so? Surrounding this matter is a lot of debate on extending the pattern, for the most part I have seen the following schools of thought:

Query objects
Extension methods
Derived Model Repositories

Of these I find query objects to be the most fascinating, I will defer to my friend RossCode to explain them here. But essentially the idea is to create a new abstract base class called QueryBase<T> and use this to create objects that contain criteria for performing these custom queries. Using this we can create two methods (one for singles, one for sets) on our RepositoryBase<T, PK> like such:

   1:  protected T GetBy(QueryBase<T> query)

   2:  {

   3:       return query.SatisfyingElementFrom(GetAll());

   4:  }

5:

   6:  /// <summary>

   7:  /// Get a listing of records that matches a custom criteria

   8:  /// </summary>

   9:  /// <param name="query">Query object to supply the criteria data</param>

  10:  /// <returns>ILIst of T or null</returns>

  11:  protected IEnumerable<T> GetAll(QueryBase<T> query)

  12:  {

  13:       return query.SatisfyingElementsFrom(GetAll());

  14:  }

What we have done is create a set of methods that take an abstract type as its parameter, thus allowing any class that inherits from QueryBase. In reality, this method is designed to be used with something like LINQ to NHibernate which would allow these custom queries to benefit from the deferred execution that is found in many data related variants of Linq, in our example however, we will be using standard Linq to Objects; I believe RossCode’s examples use Linq to NHibernate.

So using these query objects we can define separate classes for each custom query we wish to make and then pass then to either GetBy or GetAll. This has the advantage of allowing us to use only one class for the repository and yields custom results. But wait there is a slight problem with this method from a maintenance perspective. Now we are dropping this query objects all over the application, and while this may be ok for a smaller application, in larger application it could quickly turn into a mess. From a Separation of Concerns perspective we are not defining our queries outside the data access layer. The caller should not need to know anything about how the query is generated, only that it can call the function and return the result.

Lets stick with the idea of Query Objects and address the root of this problem: we want to be able to make the custom calls as dumb as possible and not have query definition logic in the layer making the call. One of the ways around this is to use extension methods (.NET 3.5). Consider the following example:

public static List<Episode> GetEpisodes(

     this RepositoryBase<Episode, int> repo,

     bool state)

     return repo.GetAll(new ActiveEpisodeQuery(state));

What this will do is attach a method (GetEpisodes) onto all instances of RepositoryBase<Episode, int> thus allowing us to contain the method to a single function. While this is not a bad approach, I do not like it because it feels so awkward; I would rather the functions be part of the class themselves, I cannot call this method through reflection should I need to later on.

My chosen way is to use derived repository classes, because:

Base classes should always be declared abstract and thus not allowed to be instantiated
Using a derived class allows the ability to hide more from the developer and make their paths less cluttered
It builds on the OO principle of encapsulation and allows us to change things at will
Using inheritance from the gives us the ability to hide things we may not need thus creating a simpler API

The major drawback to this approach is that you end up having to create and maintain more classes, because now every model will need to have a specific Repository class. A sample one could look like such:

public class EpisodeRepository :

     RepositoryBase<Episode, int>

     public List<Episode> GetActiveEpisodes()

          return GetAll(new ActiveEpisodeQuery(true));

Using this approach you can increase the amount of code that can be encapsulated inside the derived class and thus perform more complex operations on the repository objects, all while providing a simple API to the outside.

To conclude, we talked about the major shortcoming of the basic form of the Repository pattern: customization. In any data driven application you will need to create custom queries that mutate and translate data in different ways. The use of query objects can greatly enhance the clarity of the underlying logic, but without an additional layer of abstraction could pose great problems for code maintenance. To mitigate this we analyzed two possible approaches: 1) use extension methods to extend possible instantiations 2) create derived repositories for models to provide these custom data manipulations methods.

It is my personal preference to use approach #2 as it enables you to achieve complex operations with a much simpler interface. It also helps with code maintenance and readability as the code can describe to the developer what it is doing and what is involved in the operation.