In this tutorial segment I upgrade the league application to use the new ui-grid (ng-grid 3.0). Note that ui-grid is at this time still early beta, but offers the likelihood of better performance, a cleaner interface, easier edit in place, and removes the previous dependency on jQuery.
In this portion of the tutorial we add Devise integration to provide logon to the application, and provide custom pages for password reset and account unlock. This content is based somewhat on the equivalent content from the rails 3 version of the tutorial.
This will break down into three main elements:
- Provision of a registration page that matches the Devise expectations and calls the Devise register method and password change method
- Provision of a logon page that matches the Devise expectations and that calls the Devise logon method and associated methods such as password resets etc
- Provision of functionality such that AngularJS can detect that a user is not logged on and redirect the user to the logon page, rather than just having each server interaction fail
If you’ve dropped into the middle of the tutorial, you can find the code for the previous section at github: PaulL : tutorial_9. You can go to the index page for this tutorial, or you can hit the tutorial menu above and see all the posts in the Rails 4 tutorial.
In this edition I use a custom matcher to provide tailored failure messages on my Jasmine expect() statements, allowing me to get context information other than “expected ‘true’ to equal ‘false'”.
I’ve been working to flesh out the functional tests for our application – I had allowed them to fall a little into disrepair whilst I did some architectural change, and it was time to refresh the suite.
As part of my architectural changes on the application itself I had refactored a lot of code to make it common. Looking at the functional test suite it looked like it needed the same treatment. In refactoring this code I wrote some helper routines, including one that checked (for each of view, editClean, editDirty modes) whether the correct fields and buttons were enabled. All well and good, but the core of that logic was a loop through a hash, and Jasmine/Protractor reports only the line number – not which iteration through the hash we were on. Making debugging annoying – how do we tell which field it is that is enabled but shouldn’t be?