(I also posted this on the London RUG list, hopefully there aren't many people registered to both. Apologies if you are; there are many intelligent people on this list whose thoughts I didn't want to miss out on).
Hey list, I'm working on a Rails API that's the backend for an iPhone app. Given that I'll have no control over when a user may choose to up upgrade to the latest version of the app, I'm taking steps to ensure that each of my API versions are very much self-contained. When I need to bump the version, i'll simply duplicate the controllers. I've worked on apps before where you'd have multiple controller versions calling down to a shared model method - this is a time bomb I want to avoid. The smell that's now beginning to emerge is that controllers are getting fat with protected helper methods that build data structures for conversion into JSON. Normally I'd push these down into the model/some class, but like I said, I need API versions to remain self-contained. My initial thought was to suffix model methods with the API version, i.e attributes_for_json_api_v1 but that'll soon result in fat models, which I dont want. What solutions have other people used for this problem? I'm almost considering a layer in between my controllers and models, almost like a presentation layer from model to controller. Mixins could help here... perhaps something like this? https://gist.github.com/1162618 Could get messy if the controller uses a large number of models? Thoughts welcome! Cheers Ian -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
