Hi Chris, You are on a very reasonable track. You could simplify it by making Service a module which defines an interface and automatically registers includers using the included call backs. However, that seems like a stylistic difference more than anything else, and I'd be hard pressed to argue against the specificness that you are using here. I would lean away from making the whole thing more complex than it needs to be with regards to some sort of plugin architecture.
Best, Rob On Nov 17, 2011, at 13:35 , Chris Radcliff wrote: > My apologies for not being clearer; I'm still learning all the right > names for things. This isn't an ActiveRecord-based class with any > representation in the database. In fact, it might not be a "model" as > such; just a class with N types of services, defined independently. > > One service type is picked based on a given social media account URL > to provide code that can answer questions about that account. (What's > recorded in the app's Outlet model is the type of service and the > account URL, thus the confusion.) > > I've sketched out some rough example code in case that helps: > https://github.com/globalspin/plugin_test > > The closest analog I've found is Boxer, a gem that allows you to > render objects using predefined named views: > https://github.com/gowalla/boxer > > That's what I used as a model for my example implementation, with the > find_by_url idea tacked on. Does that makes sense idiomatically? If > so, I'll use it and move forward from there. If there's a better way > (subclasses? some kind of plugins gem?) then I'd love to hear it. > > Thanks, > ~chris > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
