Westwards!

Continuing from yesterday, I’ll try to integrate Authlogic today. According to the README, one needs a special Model and Session classes, which then can be used to handle/implement all authentication concerns. After the README, it’s still not clear to me how to proceed. There is a reference implementation which contains more information about how to proceed. I go with that. And almost immediate fail, due to changes in rails 3, which were already reported in 2010. Further browsing through the issues there reveals a pull request updating the README to deal with those changes. I wrangle much from the example repo into my own structure, learning about resetting the database and a little bit more about migrations. Some things are a little bit of trial and error, as the README and the code do not always match perfectly. Some things go wrong because the README update for rails 3 doesn’t match the rails 4 way to do things. When trying out the copied code, the user_session is still looking for the user class, which - of course - doesn’t exist, as I’d like to authenticate People. Reading the code reveals that the session has to be called like the acts_as_authentic. D’oh. Renaming stuff in rails is not fun. Really.

Of course, once this was all done, it didn’t work. Meh. After reconsidering the current state, I abandon Authlogic and look around for other rails solutions to authentication. Sorcery is recommended on stackoverflow and looks good and active. A refreshing change from authlogic’s five year old example repo.

Sorcery’s rails 4 compatability shines in it’s installation process. The commit is much smaller, as it doesn’t need a separate session, it integrates easily into my existing model (although I had to manually fix up the migration). The configuration is already a rails4 initializer. And finally, the hook-up to the model is a single line.

Now for actually getting new users and authenticating. Following the authentication with sorcery railscast more code is added. This looks all quite straightforward and hackable. I like this. Now the application can sign up, login and logout. Sorcery saves the day!

Now to some bones: add the actual data model. Since the number of users is still in the single digits (zero), I take the liberty and change the initial migration to add more columns.

Code Quality

Before driving on, I’ve set up the code coverage and code quality reporter from codeclimate.com. Commmit. Results. Time to add a little bit of bragging to the README.

  • Adding codecoverage adds another minute to the test runtime. That’s basically double the current runtime.
  • Completely untested code files are not counted against the coverage total on codeclimate.com. Therefore, adding the first test for an existing file actually reduces coverage, as the still-untested code is now counted as such.

To wrap up yesterday’s TODOs, I also added a license. Namely AGPL v3 or later.

Adding projects

To start fleshing out the models, I next start adding projects. Every Person can be associated with multiple Projects and every Project can have many associated Persons. Commit. Next a controller and view for Projects. As it’s already annoying to enter /new in the browser for testing, I add a few links to the welcome page. Recommended reading: routing. Implemented the complete lifecycle of projects and editing. Meanwhile code coverage is dropping like a rock, since I’m punting on those. But the tests I have do not really test anything either, except successfull execution of the controller, so the number’s value is dubious at best.

Next up: linking people and projects.

Read Tutorial about Ajaxified Create and Destroy Actions, HABTM Checkboxes, and finally a stackoverflow answer from 2010, claiming

habtm isn’t a popular choice these days, it’s better to use has_many :through instead, with a proper join model in between. […] a proper join model, with corresponding controller, allows you to easily add/remove origins with AJAX, using create/delete calls to the join model’s controller.

Found a nice plugin for two lists to move items from one to the other, which is for rails2(sic!). Nice, but no cake.

Even after (much) more reading, I come to the sad realization, that the SO answer above, really seems to be the way to go: add a cusotm search control to select people/projects and call out to the link table’s controller to add/delete connections. Changing the models will be a drag, but hopefully worth the effort. Not satisfied with the last sentence I dig around more and find a nice blog post about habtm associations in rails4, but the provided code only uses checkboxes to select association.

As a warm-up I’ve implemented searching by last name and returning of a JSON result. Commit.

Next Steps

  • Add inline person search control to /projects/:id/edit
  • Add found person to people collection
  • Check that posting that back to the server changes the associated People

TODO:

  • Improve testing regime, when understanding rails better
  • l10n, when actually adding nice views