Two-way binding for URL parameters in AngularJS

Single page applications (maybe with AngularJS?) are the new cool kid in town. So are URL parameters which are an essential part of how single page applications work. URL parameters hold the current state of an application and enable to open the application in this state (e.g. with a so called deep link). That’s how the look like:

In this example, showAll=true and filterByName=Thomas are the URL parameters. The hash (#) divides the URL into two parts: a part which goes to the server (before #) and a part which stays on the client (behind #). This is the so called anchor part which holds our URL parameters. So this part of the URL is purely for our AngularJS client!

Two way binding

Two way binding means that bind a parameter of our URL (e.g. filterByName) to a parameter of the controller (let’s say it has the same name: myController.filterByName). To achieve this, we need update our controller if the URL parameter changes and we need to update our URL parameter if the controller changes. That’s what two way mean – controller to URL, URL to controller.

Controller >> URL

Let’s start with the first way: controller to URL. Everytime a property of the controller changes, we want to update the corresponding property of the URL. To do this, we use Angular’s $watch method (see$rootScope.Scope). The method $watch allows to watch a value and do something if it changes. Exactly what we want! The code is pretty straight forward:

This code will do the following: It will create a watcher which listens on the property filterByName of our controller. If the property changes, we get the new value and set it to the URL (by $"filterByName", newVal);).

(By the way: To use the URL parameters we use a service called $location provided by Angular! That’s the default way to access the URL.)

URL >> controller

Now we only need the way back: URL to controller. As you might guess, we just use another watcher for that. But in this case we use Angular’s $on. This looks like that:

What $on does is simple: It listens for events, e.g. the $locationChangeSuccess event, which is thrown after the URL has changed. If this happens, we use the $location service to read the value from the URL and assign it to our controller.

Put it to a method!

We already have achieved what we wanted: we have a two way binding between our controller and the URL. One last thing we might do right now, is to put this into a nice method we can reuse:

If the property of our controller changes (e.g. because the use inputs data) the URL will change. And if the URL changes (e.g. because we clicked on a link) the controller will change. We have a two way binding between controller and URL!

Best regards,


Using Spring Data for database views without an ID

A database view is a great way to prepare complicated data structures right in the database and present it in a more convenient way. We usually use database views to map our technical driven database structure (with a lot of tables and foreign keys) to a more business driven structure. This means that we might join tables, concatenate values or just rename the columns, because a particular name suits better to the current business context.

To map those views to Java entities, we simply use Spring data:

However, the example above wouldn’t work. Spring would complain that the @Id annotation is missing and would throw a org.hibernate.AnnotationException: No identifier specified for entity exception.

From a business perspective, this is bad. The id of a company is its company id, the id of a person is its person id. But both are missing in the view, which has not unique identifier.

We could solve this problem by a simple trick: we invent an unique identifier – our current row number!

We can now use the row number in our Spring Data entity:

Best regards,