Brent Greeff's Profile

Thanks for the tutorial very interesting but I am not sure if its the correct usage. If you are going to define the fields in your code by defining accessors then you know what fields you want at code time. If you know what fields you want then why not just use db columns, they are easier to use. As far as I can see this is most useful when you dont know what fields you will have or they can change. What if you deploy this and later decide to change a field? I would rather query the keys in the properties column and use that to define my accessors, field forms and #show page etc. This means u can't rely on an accessor existing, but that feeds back into the same point. It does not seem wise to let the app define a schema in code but let the data remain schema-less in the DB. I think the app should not make any assumptions about what the data is. Whats the advantage of moving your schema into ruby?

There is a good post on how to use this with Cucumber:

http://pivotallabs.com/users/mgehard/blog/articles/1595-testing-omniauth-based-login-via-cucumber

It made me think though (which is never good),
is it not possible to log in as any user simply
by providing the correct provider and uid.

@ryan : Seems there is something wrong with the (reply/edit/delete) buttons, refreshing the page seems to fix it.

This might be a better solution anyway:

{
:get => "http://sub.test.host/invitations/new"
}.should route_to(:controller => "invitations", :action => "new")

{
:get => "http://test.host/invitations/new"
}.should_not be_routable

I just tried to replace the subdomain condition (before_filter)
with a routing contraint.

Unfortunately my controller specs fail. I had specs in place
that check that I get 404 when accessing certain actions
without a subdomain.

Having a look I can see that the contraint class is never called.
Seems the specs just ignore the contraint for some reason.

Works perfectly when I try it manually.