One of the problems we were having with ActiveResource at work was that we have multiple versions of services. We needed development services, “preview” services for the editorial team to test new articles and of course the production services. Developers only really want to see the development services but our designers need to see the preview content to make sure the stylesheets and javascript will work prior to going live. This gets sticky whenever there are multiple people editing the self.site variable in a model and can cause a headache when merging if values are getting overwritten all over the place.
I can’t quite understand why this isn’t a default feature of ActiveResource, but wouldn’t one think that developers would need to have at least two different environment services like development and production?
My co-worker, Matt Parker (@moonmaster9000,) imagined a better way to handle services and ta-da, Breadboard was born!
When I was implementing Breadboard on our front-end code, I quickly found that there were a few bugs that needed to be weeded out before it could be widely used by the team. For one thing, whenever you were inheriting site settings from parent classes, that would automatically be set for you, but with Breadboard it wasn’t checking if the parent class was assigned a proper site service and would automatically fall back to the default service value. I made a patch that performed the necessary checks on parent classes before the fallback to the default service.
Another interesting bug that we found was that sometimes the services were not getting set. It ended up being that when an ActiveResource model set self.site, it also set @connection equal to nil which was a key component missing the Breadboard gem that was causing some inconsistencies. A quick method write solved the problem and we were able to get Breadboard out into the workflow of the Online team.