Created a Person class containing properties such as first name and last name as well as a "residence" property that is an instance of Location.

Added the concept of "Chapter", where each Guild has a number of geographically-based Chapters. Each Chapter domain class is associated with a Guild and has a "location" property that is an instance of ChapterLocation, another new domain class that extends Location and contains properties like "floors" and "entryPoints".

Removed the Member domain class and replaced it with ChapterMember, which extends the Person class.

Simplified the Guild domain class.

Created new master list view for the Chapters and ChapterMembers and added them to the navigation bar.

The classes Angular adds to form controls to indicate the control state are based on interactions with the DOM and don't reflect the state of the model data attached to the control (for example, once a form control is marked as "dirty", changing the control value back to its original value does not re-mark it as "clean").

Some basic form control attributes (like "required") could be used to set validation constraints that Angular would use to toggle the valid/invalid class on the control, but not the validation attributes introduced in HTML5, and there was no documentation about what worked and what didn't.

Even when Angular could toggle the valid/invalid class correctly, that only indicated that the form control should be considered invalid, not why it was invalid.

(The change log for the recently released RC6 version of Angular 2 hints that some of these issues may have been addressed.)

So when I decided that the next feature of GuildRunner would be a detail component for adding or editing a guild, I knew figuring out my strategy for validating the form would be a big part of the work involved. What I came up for this release is a rough, first draft of an approach where the form takes its validation cues from validation logic and state data stored in the component. There is a lot of room for improvement should I decide that this approach is viable and a reasonable alternative to the other method of generating and managing forms in Angular 2 (dynamic forms).

In the Groovy programming language, every object that implements the Iterable interface (such as List and Map objects) comes with the every() method. The every() method takes a closure as an argument and is supposed to evaluate whether every item in the collection meets the condition set forth in the closure:

There is a JIRA ticket about this issue: https://issues.apache.org/jira/browse/GROOVY-7207. The initial commenter's guess is probably correct: that the every() method starts with a default return value of true and only becomes false if and when an item in the collection fails the conditional test, so an empty collection fails to affect the default value of true.

Still, it's not what I would have expected, and I was unaware of the behavior until I encountered it for myself.

Version 0.0.3 of my GuildRunner sandbox Angular 2 application is now available. All of the differences between this version and the previous version (minus the updates to the version number and the README file) are changes made to upgrade the application to use Angular 2 RC5 (release candidate 5).

While there were some changes to the router/routing syntax, the biggest change that comes with RC5 is the introduction of Angular modules and the @ngModule decorator. There is a long documentation page about Angular modules in the official developer guide, but essentially Angular modules allow you to bundle sets of shared injectable dependencies into a single file that provides those dependencies "downstream".

In episode 105 of the Adventures in Angular podcast, the panel spoke with one of the developers behind an open-source development tool called Augury. Augury is a Chrome extension that adds an "Augury" tab to the Chrome Development Tools panel, and that tab displays real-time information regarding Angular 2 activity on the current web page.