ngEurope: about AngularJS 1.3, new router and the future 2.0

Being passionate about AngularJS, me and two fellow JDriven colleagues visited the ngEurope conference.
The amount of presentations during ngEurope was somewhat overwhelming, especially during the mornings without any scheduled break.

Good thing I made some notes, that the slides are already available on-line and that someone published quite detailed notes for all sessions.
Without all this I might simply have forgotten about some very interesting and relevant details.

During ngEurope there was a all lot of attention for the just released 1.3 version of AngularJS and the coming 2.0 release.

Angular 1.3

The latest AngularJS 1.3 release features some great performance improvements (3.5x faster digest and 4.4x faster DOM manipulation) and much less pressure on the garbage collector (GC).
However in order to achieve this the AngularJS team did decide drop the support for Internet Explorer 8 (which is default IE version on Windows 7).

To allow for even more (optional) speed improvement one time (one way) binding support has been added.
Using one time binding no $watch will be registered for the binding; typically you would use one time bindings to speed up rendering the elements of ngRepeat.

Additionally a lot of improvements are done on the ngModel directive.
First of all a $validators pipeline had been introduced as an alternative to invoking $setValidity from a parser / formatter function.
Which also fixes the “input not showing invalid model values” bug ( #1422).
Yet another great improvement are the new async validators that allows for (asynchronous) model validation on the back-end.

The ngModel directive is now accompanied by the ngModelOptions directive that allows you to configure (the controller of) the ngModel directive.
We now can specify when we want the model value to be updated. For instance after a short delay (a so called debounce) or on blur (i.e. when focussing another field).
And using ngModelOptions we can now configure the usage of (jQuery) style getter / setter function on our model (instead of using plain data properties).

Using ngMessages (multiple different) error messages can now be shown much easier in a switch–case like style for a form element.

Besides preformance- and ngModel (related) improvements AngularJS also features some other noteworthy features:

  • composable SVG’s: it’s now possible to directly use SVG as a template of a directive by additionally specifying “templateNamespace:’svg’” in your directive declaration
  • allOrNothing: certain expressions (i.e. {{}} in <img ng-src="users/{{}}/avatar.png">) will only be rendered when completely available (i.e. preventing unneccessary additional image requests)
  • $watchGroup: $watch for more than one property
  • strictDI: checks during bootstrap if all components are properly annotated for minification; this can be enabled by adding the strict-di HTML attribute to the ng-app attribute or using the angular.bootstrap function (that could also be used from a Jasmine test)
  • ngAria: new module to more easily embed Accessible RIA (Rich Internet Applications) in your AngularJS application

The New Router

For the future AngularJS 2.0 a new router has been developed that is currently also being backported to Angular 1.3.

Similar to Angular UI Router the new router is also based on (nestable) states.
But also brings new features like dynamic loading and child apps support allowing a single app router to be splitted into sub routers.
Also it possible to add lifecycle hooks on navigating to or from a router state (i.e. displaying a message in case of unsaved changes).

AngularJS 2.0

(day 1 keynote slides, AtScript slides and Angular 2.0 Core slides)
During ngEurope the future AngularJS version 2.0 did receive quite some attention.

Although version AngularJS 2.0 is still in its design phase (with basically only really the injector and router in place)… one thing is for sure…
version 2.0 of AngularJS will differ hugely from its current (1.3) AngularJS version.

First of all the default ‘language’ for developing an AngularJS 2.0 applications is no longer ECMAScript5.
Instead the future 2.0 of AngularJS will be developed in AtScript which is superset of the ECMAScript6 (final draft planned for januari 2015) with a whole lot of extras like types (checked during compile times as runtime check), Java-like annotations, generics and introspection (somewhat similar to reflection in Java).
Since AtScript is currently not supported by any browser (even ECMAScript6 isn’t currently 100% supported), the Traceur transpiler is used to generate ECMAScript5 from AtScript.
Although AtScript is the default way to developed AngularJS 2.0 application, it’s also fully possible to still use ECMAScript5 (although it’s kind of verbose).
A big disadvantage of using AtScript is that is breaks with your existing toolchain.
Some tooling (JSHint, ESHint) currently not even (completely) supports the upcoming EcmaScript6, let alone AtScript (being somewhat tied to Angular 2.0) support might never be added for certain tooling (forcing you to stop using the tool or find a replacement).
Off course one could still use ECMAScript5 to develop Angular 2.0 application, but personally I find this approach to verbose and also somewhat error prone.

Beside AtScript a whole lot of other huge changes are made in AngularJS.
First of all (although not an extreme change) the template notation is somewhat change.
Instead of using custom attributes (i.e. ng-click) we now using (round) brackets to attach event listeners (i.e. <button (click)="addTodo()">).
Additional the names of custom attributes directives (i.e. ng-repeat) are now place between square brackets to easily differentiate between normal HTML and custom attributes.

Way more extreme changes are made in the way you write your AngularJS code.
Controllers, the (dreadful) Directive Definition Object (“DDO”), $scope, angular.module and jqLite are all being eliminated.
Instead of the cumbersome traditional way of declaring a directive one can now simply (Java-style) annotate a class with either @TemplateDirective (i.e. ngRepeat) or @DecoratorDirective (i.e. ngClass).
And instead of using a controller one could uses a @ComponentDirective annotated class.
Due to the usage of @ComponentDirective (and @TemplateDirective) the $scope is no longer needed (and therefore is removed).

Since AngularJS 2.0 will only support the most recent (evergreen) browsers (be prepared to so say goodbye to IE9) jqLite is no longer needed.
By using native DOM in 2.0 the performance can be improved even further; but although AngularJS 2.0 won’t be use jqLite (not jQuery) you can still use jQuery in your own code (although I personally would not suggest that).

Instead of using AngularJS (dependency injection) modules (created through angular.module) 2.0 will use ECMAScript6 modules and the types of constructor arguments to specify which service to inject (as opposed to AngularJS 1.x which used the name of the argument).
This approach is very similar to how the Spring Framework does injection for Java application and very neatly integrates with the usage of ECMAScript6 modules.
During the “Angular 2.0 Core” presentation a 2.0 implementation of a TabContainer and TabPane directive was shown.
Instead of using a require (like in a Angular 1.x directive declaration) the TabContainer we can now simply be injected by adding tabContainer: TabContainer to the constructor of TabPane.
Additionally the TabContainer can now (instead of a manual query of its TabPane children) simply add tabs: Query<TabPane> (using generics) to inject the TabPane’s as a constructor argument.


  • Angular 1.3 by Jeff Cross & Brian Ford (slides)
  • The New Router by Rob Eisenberg (slides)
  • Keynote (of day 2) on AtScript by Miško Hevery (slides video)
  • Angular 2.0 Core by Igor Minar & Tobias Bosch (slides video)
  • ES6 in Angular 2.0 Erik Arvidsson & Vojta Jína (slides video)
  • ng-europe, Angular 1.3, and beyond: blog post of the AngularJS team as wrap up of ngEurope about AngularJS 1.3 and the future 2.0
  • Finally… links to almost all slides can be found here

Grails Generate Asynchronous Controller

Since version 2.3, Grails supports asynchronous parallel programming to support modern multiple core hardware. Therefore a new Grails command is added to generate asynchronous controllers for domain classes. The generated controller contains CRUD actions for a given domain class. In the example below, we will generate a default asynchronous implementation of a Grails controller. Continue reading

Gradle Goodness: Changing Name of Default Build File

Gradle uses the name build.gradle as the default name for a build file. If we write our build code in a file build.gradle then we don’t have to specify the build filename when we run tasks. We can create build files with a different name other than build.gradle. For example we can define our build logic in a file sample.gradle. To run the tasks from this build file we can use the command line option -b or --build-file followed by the file name. But we can also change the project settings and set a new default build file name for our project. With the changed project settings we do not have to use the command line options -b or --build-file.

Continue reading

Grails REST: Generate RestfulController

Since version 2.3 Grails has excellent support for creating REST APIs. This new support comes with some new console commands. Besides the well known generate-controller command, Grails now comes with a new command which let you generate restful controllers for a given domain class.

In the following example, we will create a restful controller using the new generate-restful-controller command.

First we create a domain object

Second we will generate the REST controller using the new command:

This command will generate a restful controller with the name MovieController with a default REST implementation. Notable is that this generated controller does not extend RestfulController<T> but gives you a full implementation of the REST functionality inside the actions.

Below you can see for example the default implementation of the index method of the generated restful controller.

Furthermore this command will generate the REST responseType settings so both JSON and XML formats are supported.

Code written in Grails 2.4.1


Groovy Goodness: Closure as a Class

When we write Groovy code there is a big chance we also write some closures. If we are working with collections for example and use the each, collect or find methods we use closures as arguments for these methods. We can assign closures to variables and use the variable name to reference to closure. But we can also create a subclass of the Closure class to implement a closure. Then we use an instance of the new closure class wherever a closure can be used.

Continue reading

Spocklight: Indicate Class Under Test with Subject Annotation

If we write a specification for a specific class we can indicate that class with the @Subject annotation. This annotation is only for informational purposes, but can help in making sure we understand which class we are writing the specifications for. The annotation can either be used at class level or field level. If we use the annotation at class level we must specify the class or classes under test as argument for the annotation. If we apply the annotation to a field, the type of the field is used as the class under test. The field can be part of the class definition, but we can also apply the @Subject annotation to fields inside a feature method.

Continue reading

Stateless Spring Security Part 2: Stateless Authentication

This second part of the Stateless Spring Security series is about exploring means of authentication in a stateless way. If you missed the first part about CSRF you can find it here.

So when talking about Authentication, its all about having the client identify itself to the server in a verifiable manner. Typically this start with the server providing the client with a challenge, like a request to fill in a username / password. Today I want to focus on what happens after passing such initial (manual) challenge and how to deal with automatic re-authentication of futher HTTP requests.

Common approaches

Session Cookie based

The most common approach we probably all know is to use a server generated secret token (Session key) in the form of a JSESSIONID cookie. Initial setup for this is near nothing these days perhaps making you forget you have a choice to make here in the first place. Even without further using this “Session key” to store any other state “in the session”, the key itself is in fact state as well.  I.e. without a shared and persistent storage of these keys, no successful authentication will survive a server reboot or requests being load balanced to another server.

Continue reading

Stateless Spring Security Part 1: Stateless CSRF protection

Today with a RESTful architecture becoming more and more standard it might be worthwhile to spend some time rethinking your current security approaches. Within this small series of blog posts we’ll explore a few relatively new ways of solving web related security issues in a Stateless way. This first entry is about protecting your website against Cross-Site Request Forgery (CSRF).

Recap: What is Cross-Site Request Forgery?

CSRF attacks are based on lingering authentication cookies. After being logged in or otherwise identified as a unique visitor on a site, that site is likely to leave a cookie within the browser. Without explicitly logging out or otherwise removing this cookie, it is likely to remain valid for some time.

Another site can abuse this by having the browser make (Cross-Site) requests to the site under attack. For example including some Javascript to make a POST to “” will have the browser make that request, attaching any (authentication) cookies still active for that domain to the request!

Continue reading