‘this.datasource’ is awesome in ColdFusion 11

Normally In ColdFusion applications we set up the datasources in ColdFusion Administrator or using the Admin API.So this makes very difficult for our Application to be portable across different ColdFusion server. Because while migrating to another ColdFusion server first of all we have to recreate all the datasources again.

(Note: Once I have tried to back up all my datasources using the neo-datasource.xml file(which stores all datasource info) of my old CF server. But that does not works because of the password encryption/decryption issues.By password encryption issues, I mean the database password that we give while creating a datasource, this password gets stored in encrypted format in our ColdFusion server.So if we migrate our neo-datasource.xml file from Old CF server to new CF server , The new CF server can not decrypt those passwords properly.)

ColdFusion 11 brings a new features for creating datasources in application level instead of messing up with CF Admin.
We can define all our datasource details in Application.cfc.

 this.datasources.dsn1 = {  "database"="regression",
                   "host"="localhost\MSSQL2008", 
                   "driver"="MSSQLServer", 
                   "username"="sa", 
                   "password"="mindfire" };
 
 this.datasources.dsn2 = {   "driver"="MSSQLServer", 
                   url="jdbc:macromedia:sqlserver://localhost\MSSQL2008; 
                   databaseName=regression; 
                   sendStringParametersAsUnicode=false; 
                   querytimeout=0; 
                   MaxPooledStatements=1000", 
                   "username"="sa", 
                   "password"="mindfire"};  

If you are using built in DB drivers that are shipped with ColdFusion , then just specify the driver name and the corresponding driver class will be picked up by ColdFusion. In neo-drivers.xml, you can find all the possible values for the driver.

But if you are using your own custom driver, you can use this syntax.

this.datasources.customDSN = { "driver" = "other", 
                 "url" = "jdbc:sqlserver://localhost\MSSQL2008; 
                 databaseName=pubs; 
                 sendStringParametersAsUnicode=false; 
                 querytimeout=0; 
                 MaxPooledStatements=1000", 
                 "username" = "sa", 
                 "password" = "password", 
                 "class" = "com.microsoft.sqlserver.jdbc.SQLServerDriver"}; 

Note: But If there is a server wide datasource with the same name exist, then application level datasource will be overridden by server level datasource.

Playing with Scope Inheritance In Angular

In my previous blog I have discussed about the prototypical inheritance in Javascript, In AngularJS, a child scope normally prototypical inherits from its parent scope.Today while working with angular I found a interesting concept regarding prototypical inheritance in angular. Now lets directly start with an example,

Here is the PLUNK.

In the above example We have created an array “Skills” which contains a set of skills, and a model “mySkill” to store a particular skill in $scope. We are using the “Skills” array to populate our check boxes and ‘mySkill’ model to store the skill selected by the user.Finally we are showing the skill selected by the user. But this will not work the way we are  expecting.

It will not update our model ‘mySkill’ according to the checkbox selected by the user. This looks like a strange issue. Now the question is why Its not updating our model properly? This is because ng-repeat creates a new child scope which is prototypically inherited from parent scope and the child scope gets its own property(‘mySkill’) that hides/shadows the parent property of the same name, But does not update the parent scope ‘mySkill’ property. This is not something AngularJS is doing – this is how JavaScript prototypical inheritance works.  Directives like ng-repeat, ng-view and ng-include create new child scope where this kind of problem occurs.

This issue with primitives can be easily avoided by following the best practice of always have a ‘.’ in ng-models.Having a ‘.’ in models will ensure that prototypical inheritance is in play. So, we should use

<input type="text" ng-model="someObj.prop1"> rather than 
<input type="text" ng-model="prop1">.

If you really want/need to use a primitive, then we can use $parent.parentScopeProperty in the child scope which will prevent the child scope from creating its own scope.

<input type="text" ng-model="$parent.prop1">

Now to make our example work properly we can modify it as below,

Here is the PLUNK.

So what exactly we did is we have modified  $scope.mySkill = “Java” to $scope.mySkill = {fav: “Java”} and used mySkill.fav as our model. So now inside ng-repeat It will not create a duplicate mySkill property in the child scope instead it will update the parent scope mySkill.fav property and everything will work as expected.

This is one of the “Best Practices” in Angular JS.

Summary:

If we use a primitive type (as ‘mySkill’ in 1st example) as model for data binding, essentially ng-repeat will create a new child scope property with the same name . Changing the child scope property’s value (i.e., using ng-model, hence child scope property mySkill) does not change the  parent scope mySkill property. So in my first example above, each child scope gets a mySkill property that is independent of the mySkill property defined in the controller or the parent scope. But if we will use a Object type , It will use prototypical inheritance and always update the property on the parent scope.

Custom Validation In Angular Js

Angular JS having very strong support for form validation. It’s having builtin $error object,predefined CSS classes and patterns that makes the form validation much easier. Still there are plenty of cases where we can not use angularjs default validation.Its off course not possible to cover all the cases.

So we can write up our own custom directives for adding custom validation to our application.What we really want to do is to build a directive that will require ngModel(require: ‘ngModel’). Requiring ngModel will pass the ngModelController into the linking function as the fourth argument. The ngModel controller has a lot of handy functions on it, in particular there is $setValidity, which allows us to set the state of a model field has $valid or $invalid as well as set an $error flag.
The ng-model directive provides two arrays of functions to which the custom validation logic can be hooked:i.e

  1. $parsers
  2. $formatters

Usage of both of these arrays looks similar, but they are invoked under different conditions.

$parsers:

Array of functions to execute, as a pipeline, whenever the control reads value from the DOM. Each function is called,
in turn, passing the value through to the next. The last return value is used to populate the model. Used to sanitize /convert the value as well as validation. For validation, the parsers should update the validity state using $setValidity(), and return undefined for invalid values.

In most of the cases, $parsers is the right option to handle the logic of custom validation. Functions added to $parsers are called as soon as the value in the form input is modified by the user.

$formatters:

Array of functions to execute, as a pipeline, whenever the model value changes. Each function is called, in turn, passing the value through to the next. Used to format / convert values for display in the control and validation.
Formatters are invoked when the model is modified in the code. They are not invoked if the value is modified in the textbox. $formatters are useful when there is a possibility of the value getting modified from the code.

Example:

Suppose we want to validate our username. It must be alphanumeric only.

Though we can achieve the same kind of validation easily using ng-pattern, I have shown this example just for the demo purpose to show how $parser and $formatter works. Here is the PLUNK.