Patient login

I just realized that adding Patient login is going to be a very complex change, because now both Practitioners and Patients can be logged in, and I’ll need to heavily differentiate between their experiences.

So, I’m canceling those two items on my list and moving on to the mailchimp changes.

D’oh

I thought there was a bug in Clearance, because I didn’t see the password change in the DB. Of course it wasn’t changing because I was setting it to the same thing every time. Ug. I spent some quality time with the Clearence code in the debugger though.

I’m calling it a night though, my neck is killing me.

For tomorrow:

  • patient registration
  • logged in patient appointment scheduling
  • super-simple mailchimp template
  • mailchimp setup for confirmation email

We have Clearance, Clarence

So, I’ve spent the last few hours mucking with the Clearance based authentication system I’m using. I’m trying to get it to reset passwords correctly. I haven’t gotten that working yet, but I have cleaned up a bunch of stuff related to new accounts and logging in, so it’s been worth it.

I’ve basically subclassed all the Clearance classes, mostly so that I can define a layout for the pages, but there are a few cases where I’ve overridden the functionality.

The trickiest part is figuring out all the routes. Clearance installs a bunch of routes, and they’re not always obvious. Fortunately there’s:

rake routes

To list everything that’s defined, even if it’s deep down in a gem.

The Clearance guys were nice enough to link to the relevant video on their readme page.

Public Calendars

Before I took a break to make some drinking chocolate and watch Mega-Shark vs. Giant Octopus (Starring Debbie Gibson), I got public calendars working. If you’re logged in, you see the full event details on the calendar, if you’re not logged in, you just see ‘unavailable’.

I also set up subdomain handling, so that if you go to, say, reiki-center.innerlighttools.com/calendar/2011/02, you’ll see the calendar for that practitioner. I’ll be using the subdomain stuff all over the place in the future. It was actually trivial to do once I read this turorial.

  • appointment model
  • appointment controller
  • appointment view for user, with basic CSS
  • expand user registration to handle business name
  • seed data for a few users/appointments/events
  • subdomain handling in dev
  • appointment view for anonymous patient
  • appointment list for next two days on Center page
  • patient registration
  • logged in patient appointment scheduling
  • super-simple mailchimp template
  • mailchimp setup for confirmation email

:has_one, :idiot

So, I just learned the following:

:has_one

Specifies a one-to-one association with another class. This method should only be used if the other class contains the foreign key.

I had thought, erroneously, that when you created a :has_one relationship, that you also set :belongs_to on the associated object. This is often shown in examples – but it only works of you’ve set a foreign key field on both Models. I only had it on one, so my code kept breaking trying to access the associated model from the main model. So it comes down to whether you use :has_one or :belongs_to entirely depends on which one of them has the key. At least it’s working now.

Day 2: In which I start with the low hanging fruit

I have coffee, I’m ready to go. Here is the list:

  • appointment model
  • appointment controller
  • refactor appointment into event
  • appointment view for user, with basic CSS
  • expand user registration to handle business name
  • seed data for a few users/appointments/events
  • subdomain handling in dev, and on server
  • appointment view for anonymous patient
  • appointment lis for next two days on Center page
  • patient registration
  • logged in patient appointment scheduling
  • super-simple mailchimp template
  • mailchimp setup for confirmation email

Scopes (Not the Monkey Trial) in Rails 3

OK, bad pun. This is the life I lead.

Tonight was the first time I’ve gotten to use the Scopes feature in Rails. I’d heard about named_scopes a while back, but hadn’t gotten to a point where I needed one, so I didn’t really know how they worked, despite skimming a few articles on them.

I started with the Railscast on named_scope, which is a great intro, but I soon discovered that they’d changed the syntax in Rails 3. Fortunately I had enough of a grasp on it by then that I was able to change my code to the new style with the help of EdgeRails.info.

It was an easy change, and made my code much cleaner.

What I did was add a ‘today’ scope to the slot class, so that I can grab all slots for a given day like so:


scope :today, lambda {
dt = Date.today
where("slots.start_at >= ? AND slots.end_at
dt.beginning_of_day, dt.end_of_day)
}

I had to use a lambda in there so that the date code would evaluate when the scope was called, not when the class was first loaded. The syntactic sugar that Rails adds for date handling is wonderful, it makes the code quite a bit easier to read.

That’s it for tonight, I’ll hit the low hanging fruit on appointments in the morning.

Calendars in Rails, redux

I ended up making a few decisions. First, I figured out how to refactor the appointments and the events into a single Event class that contains many time Slot objects.

Because I didn’t need the day-spanning feature in event-calendar, I decided to kill it and go with a simpler solution based on the Railscasts code I mentioned previously. What that gives me is a nice bare Calendar framework that I can customize all I want without breaking any of the magic that may be hiding under the covers. I hate to end up in Not Invented Here territory, but I think in the end it’ll make me more agile if I really understand the calendaring code. I suspect a lot of my future work will be in that area.

So now I have a calendar grid displaying with time slots listed in it. I need to build a Day View for scheduling hour-by-hour. I also need to finish ripping out he appointment code and replacing it with the Event classes.

I updated to Rails 3.0.4 as well.