This seems like something that people must have already worked out, so I'm probably just not finding the right combination of search terms. If I were to share some domain classes between one Rails application and another -- what's the right way to make that happen? For instance, imagine I'd already written a retail banking site with CreditCard, CreditCardTransaction, and other credit card domain objects, as well as bank accounts and so forth. Now i want to build an internal application for credit card fraud, and i'd like to re-use my domain objects and share a database, but host this application internally. What's the "Rails Way" for that? For shared non-application-specific functionality, I imagine I'd use a plugin, but it doesn't sound like the right choice for share domain or application-specific code. Thoughts? TIA - Geoffrey
on 2007-06-29 02:47
on 2007-06-29 04:48
If you want to share the Ruby classes but have separate databases you should probably look at engines or the related approaches to carving out part of an app and sharing them (models, controllers, views, etc). If you want them to share the same database then just use REST web services to share the functionality. Michael
on 2007-06-29 05:06
On Jun 28, 10:47 pm, Michael Latta <lat...@mac.com> wrote: > If you want to share the Ruby classes but have separate databases you > should probably look at engines or the related approaches to carving > out part of an app and sharing them (models, controllers, views, > etc). If you want them to share the same database then just use REST > web services to share the functionality. Even with a web service, assuming I want to unmarshal the message into an object, I'm looking at having a shared domain class, no? I mean, yes, I could write the class in both applications or use svn externals to get there, but neither of those seem ideal. I'll look into Engines; I've heard the word, but that's about it, so I might as well know what it means.