Gems are good for modularity. They don't have to be "public". On Mon, Feb 1, 2010 at 9:31 PM, Chris McCann <[email protected]> wrote:
> SD Ruby, > > What's the best (as in DRY) way to provide functionality that can be > used by two different applications? > > I've got two Rails apps that share a DB. One is a back-office > application for the folks who administer a national fraternal > organization and the other is a front-end app for local chapters and > members of that same organization to manage their membership, run > their chapters and also provides a publicly accessible web site for > each chapter. > > The two apps serve very different needs but have particular > functionality in common. For example, the administrators need to be > able to process and record dues payments by credit card and check that > are snail-mailed to the national organization. > > The average age of members is well north of 60 years old so processing > payments received through the mail is and will be quite common for the > foreseeable future. That functionality is built (using Active > Merchant for the credit cards) and works well. > > I now need to provide the same credit card capability in the other > application as a member self-service feature, with the eventual goal > of having the majority of the membership use that method to pay their > dues online. > > But I'm struggling a bit with an elegant solution to expose my > ActiveMerchant-based CC solution in the front-end app that's used by > the members. Is Active Resource the way to go? Is there a better way > to modularize functionality like this that can be used across > applications? > > If anyone here has some advice on best practices in this situation I'm > all ears. > > Cheers, > > 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
