WebApi: File upload and download using JQuery and submit button | Kenny Tordeur

WebApi: File upload and download using JQuery and submit button | Kenny Tordeur

Posts on compile function in directives

Just some posts I found that were helpful.

https://github.com/angular/angular.js/wiki/Understanding-Directives

http://plnkr.co/edit/qrDMJBlnwdNlfBqEEXL2?p=preview

http://docs.angularjs.org/guide/directive


http://stackoverflow.com/questions/14565121/whats-the-difference-between-the-2-postlink-functions-in-directive

http://www.cheatography.com/proloser/cheat-sheets/angularjs/

AngularJs and Xml in IE8

Directives are the backbone of AngularJs.  They are perfect for working with Xml.  Internet Explorer 8 does not render Xml on the DOM correctly.  My quick fix is to use ng-include.  I've probably blogged about this before.  But today I lost an hour of time working on a sample page for a very complex directive.

On my second pomodoro break, I decided to look at the xml.  It looked fine.  Then I put it in a separate file, used ng-include and it worked perfectly in IE8.  It always worked in Chrome.  I usually develop in Chrome then work through any IE8 issues. This process speeds up my development cycle.

<div ng-include="'myfile.xml'"></div>
Be sure to use single quotes around the file name.

Note: you can also load files dynamically with ng-include.

XML Schema and SSDT Sql compare

I am really enjoying the Sql Compare tool in Visual Studio 2012.  One rough edge is when working with XML Schemas in sql.  Sometimes they update sometimes not.  In development I just drop my table and re-run the schema compare.  In deployment, that will have to be scripted.  The advantage is I don't have to write scripts during development.  This is a nice time saver.

Why AngularJs MVC is Different

In the Asp.net MVC framework and in Sencha each layer is clearly defined.  In AngularJs the model is 'compiled' for lack of a better term.

In AngularJs the model definition can occur in many different places, this is why it is different.  Adding a new model item to a form is simple.  In an html form with an html input node, simply add an html attribute of ng-model="person.name".  When the page is compiled, AngularJs crawls the DOM, and automatically binds all of the ng-model directives to the $scope object.  $scope is where we find the M in MVC.  Scope also contains other things.

Reading from the model is also easy, simply wrap it in curly braces in the html.
<div>{{person.name}}</div>

When I was first learning AngularJS the examples confused me.  I often thought  "why I would want to see what the user was typing somewhere other than in the input box?"  You don't!  In your form you don't want to have {{person.name}} display on the input form.  It is redundant.  You will want {{person.name}} inside of ng-repeat for an index page that lists all the records on the page.


Generating the model from a form is not the only way.  Usually the model is populated from a service located in a controller.  Note, the $scope variable is passed in via the dependency injection framework in AngularJs.  $scope is a canned object that is injected into your method.  After a while your controllers start to have many things passed in.  This is just the simplest example.

var MyCtrl = function($scope){
  id = '';
 $scope.person = MySvc.getById(id);
}

Re-Usable Directive Base in AngularJS

This post describes one method for making a re-usable directive base in AngularJs.  There are other patterns than can be used to wrap this method.

I have to admit something about this feels wrong!  But it works.

Look for the RED  text in the code, this re-mapping of data is what makes this pattern work.  If you try using "this.someArg1" directly in the code...'undefined' error.

I would not use this 'pattern' if you are making a one off directive.  I am making directives for xml documents.  With 10 different xml nodes that all need the same base...I don't want to copy and paste that much code.

I'll show the usage first to add some context to the myFancyBase function. "p:" stands for person in a random xml example.

MyApp.directive('p:Name',['dependency1','dependency2',function(d1,d2){
    var fb = myFancyBase().getBase();
     fb.someArg1 = d1.foo;
     fb.someArg3 = 'whatever';
     return fb.getDirective();
}])

I've color coded things to give you a headache and to help match up instances of the same vars.

var myFancyBase = function(){

   var getBaseFn = function(){
            //This mapping just feels wrong
             var someArg1=this.someArg1,
             someArg2 =this.someArg2,
             someArg3=this.someArg3;

            var getDirectiveBaseFn = function(){
                          priority: 50,
                          replace: false,
                          transclude: false,
                          restrict: 'E',
                          scope: false,
                          link: function(scope, element, attrs) {
                             //special sauce for my fancy directive
                              var x= foo(someArg1);
                              var y = bar(x + someArg2);
                          }
                   }

        return{
            getDirectiveBase:getDirectiveBaseFn,
            someArg1:undefined,
            someArg2:'my default setting',
            someArg3:undefined
         };
    }

  return{
     getBase:getBaseFn
  };
}

.Net WebApi - four months later

In WCF it is easy to have one big class/service that is loaded with functions.  In WebApi it is best to limit the commands to four or five actions.

• GET()
• GET(id)
• GET(id, oneMoreVar) - I don't recommend this unless it really makes sense
• POST
• PUT
• DELETE
• OPTIONS- if you want to get real fancy.

Don't try to make your own verbs unless you know all the browsers you need to support allow for custom verbs.  Internet Explorer 8 does not support custom verbs.

In one app I've recently worked on, the data was being stored as xml in sql.  I would highly recommend one WebApi controller per xml column and one WebApi controller for managing the non-xml columns.  Having a controller just for the SqlXml DML works nicely for 'PATCH' style commands, like replacing the text in an xml node vs. overwriting the whole document.

I would also recommend creating your own abstract base class for the WebApi controllers.  The base class will inherit from the built in ApiController base class.

When it comes to testing, create abstract base classes for your test classes. One for each verb.  The set up is fairly different for each verb and once the controller is initialized you are stuck with what you've got in your setup. 

 

If the controller logic is minimal and if you have a strong abstract base class for the WebApi Controllers, you may need to only test your first controller.  In my case the inherited controllers only had a few lines of code and no logic.  I could have even abstracted them away to a config based solution, but I like the option of being able to override base classes if needed.