This is the third part in series "Implementing MVC Site using Csla and ExtJs". The first two parts can be found here:
Part 1 - Introduction
Part 2 - Solution Structure
In the previous 2 posts I mentioned decisions behind some of the technologies used in the demo as well as the file structure.
If you remember I stated that url reguest like:
http://server/<Controler>/<Action>/<Parameter(s)>
is mapped into Controller.Action(Parameters...) call.
So lets take a look at the our example - what happens when we click on Customer link:
As you can see the url follows the pattern we mentioned above. So with the assumption from above we would presume that the CustomerController.List() method would be called. Lets take a source code of that Action/Method to se how do we get to the view:
Where is the beef? List method seems to create some SelectList object, and then passes it to the method called View as a parameter. Hmmm... OK, method View probably results in View called List being rendered, and we are passing it SelectList for perhaps databinding...
Where is CSLA code? Well, customerFactory is an instance of ReadOnlyListFactory class. RetreiveAll() returns CustomerList instance which is ReadOnlyBase implemenation. But why not use CustomerList.RetreiveAll() - factory method? Instead of using Factory Method design patern, we are using Abstract Factory, moving Create(), and Fetch() outside of our Csla BOs, for the purpose of easier Unit Testing. I will explain the details of this in one of the future posts that has to explain the whole process of testing all of the app layers in Csla - which will probably be the best part of this demo.
For now, all we need to know is that there is AbstracBusinesstFactory class that defines following:
and then the ReadOnlyListFactory.RetreiveAll() looks like this:
and cutsomerFactory is instantiated with, in controller's constructor with:
var customerFactory = new ReadOnlyListFactory<CustomerList,CustomerInfo>();
Again all we care for now is that customerFactory.RetrieveAll() serves same purpose as customerList.RetriieveAll().
What does then SelectList object do? It is used by Html.DropDownList() helper method of the MVC frameowrk (there are number of others) that renders html <select>element for us. All that SelectList does is it takes the IList implementation, like CustomerList, the other two parameters being Key Value (CustomerID)and Display Value (CustomerName), for SelectList.
Lets now take a look at the Html source of the List.aspx:
This actually is all of the Html that is in the List.aspx view, by the way. I will explain later how the Order and OrderDetials grid "Magically" appear on it.
But wait, when I run the sample site the drop down I see has a different style from standard windows drop-down. In addition to that we can see that the drop down has a type-ahead, kind of like Intelisense...
How come? When I look at the html source very simple <select> element is rendered...
Simply put this is where ExtJs comes in. We have used ExtJs DropDown control, that simply can "inherit" from the Html element/instance, and extend it to implement some new functionality, like in this case. What complicated JS did we have to write to do this, you might ask?
Well here it goes, this is all that is needed:
It appears that the script creates an Instance of Ext.form.ComboBox() class (I know, I know some of you might say: "But wait JS does not support classes". Well ExtJs does, and so does JQuery, and Prototype - 3 most popular Ajax libraries on the planet). And it passes parameters, like typeAhead: true, and transform:'customerList'. TypeAhead is obvious, but transform parameter is interesting. It tells ExtJs.for.ComboBox class which html <select> element it needs to enhance/transform. And that is all. Oh, by the way there is an extra call that registers JS function refreshOrderGrid() to listen to "select" event on our drop-down, after the constructor. That is the extCombo.addListener() call.
But Nermin, we should not use JavaScript, although that chunk of code looks cool. Well then neither should folloing companies, all of which have sites built on top of ExtJs:
Adobe, Aetna, AIG, Alcatel-Lucent, Amazon.com, Best Buy, Boeing, Borland, CA, Canon, Capgemini, Cisco, CNN, Dow Jones & Co., EMC, Fidelity, General Electric, Hallmark, HP, HSBC, IBM, Mott MacDonald, NATO, NetApp, Nortel, Northrop Grumman, Panasonic, Pixar Animation Studios, Qualcomm, Inc., S&P, SAP, Siemens, Sony, Symantec
The difference between the JS that used to get us burned in the old ASP days and ExtJs is that ExtJs is extremely simple, it is used strictly for UI rendering - no business logic in JS, and allows for all of the modern language constructs in JS. Building extension methods, overloads, custom expressions is easier in ExtJs than in C#. And would you rather have unreadable and unmaintainable Java Script that some of the Web Forms control generate (that by the way is not compatible with all of the browsers, and can't be touched - it is generated), or would you use this easily extensible JavaScript library directly. Unlike Web Forms generated script this is easily manipulated for style, adding new features etc. One can inherit from Ext.form.ComboBox class create its own extenions override existing methods behaviors. Limit is only your cretivity.
This will just get more interesting in the next post when we discuss the "magically" appearing Order, and Order Detail grids. Grids that support everything that ASP.NET Web Forms GridView do and lot more. And it is my humble hope that the article will prove to you that this results in by far simpler and easier to maintain code, that is easily testable, and more stable.