G'day James, My view on this is that you have one application with a role-based layer wrapped around it that allows you surface just those parts of the app that apply to a single role (in your case, the roles are customer and staff ... member). If you hook the role-based layer to user sign-on the single app can pretty easily figure out what to surface for each user. Put an admin function on the role-based data and you get the flexibility of adding roles and migrating functionality between them without any recoding. And then, of course, you're back to enjoying ActiveRecord.
I've implemented this so many times that it's an enduring architectural pattern in almost all of my apps. For example, mozo.com.au implements the public site and all the back-office admin that supports it in one application. We quite often migrate functions from one user role to another and even create new roles as the business expands and more people come on board. The public punter doesn't see any of this, of course, but it's all there. For a while, I've been meaning to put up on github a Rails Engine that does this, so if you're interested in getting a sneak peek at the code, I'd be happy to help you through it. What's the down side to my solution? Well, if you want 2 deployments, each deployment will carry some code that effectively never gets used. I think that's a small price to pay for the flexibility and reuse you get. cheers Mark On Fri, Oct 2, 2009 at 12:26 PM, Matt Allen <[email protected]> wrote: > Hi James; > Very timely post to the list. I am currently working on an app for a > client that talks to their system through ActiveResource. It's not > difficult to work with, but the gotchas are many. > > Things like you can't use regular relationships, has_many, belongs_to and > their cousins don't work between Resource and Record. I end up making a > record of the same name and almost proxying through it. I end up > namespacing the AResource models so as to not confuse the issue. > > Also, testing can be a PITA. I have just knocked up a FakeWeb > "blueprint-esque" type class that puts FakeWeb into a known state. The main > reason for this is that FakeWeb does not look at the POST body, so the URI > becomes the key. So if you were posing to say, "/users.xml" to create a user > and you wanted to test it failing, you have to clear out the FakeWeb > registry and put in one that has the <errors><error>....</error></errors> > ActiveResource response to have it fail on you. > > So, my conclusion is that it's *probably* a little to painful to use app > wide, luckily the app i'm writing only touches the other system when making > payments, so not very often. > > Hope this helps, > Matta > > On Fri, Oct 2, 2009 at 12:14 PM, James Healy <[email protected]> wrote: > >> >> Hi Folks, >> >> I'm in the design stages of a fairly standard new Rails project that >> calls for two applications - one for staff and one for customers. >> >> The data model for each is identical, and initially at least they will >> be hosted on the same machine. >> >> The way I've approached this in the past is to share models between the >> apps and point them at the same database. This will work, but it strikes >> me as the kind of scenario ActiveResource is designed to be used in. >> >> ActiveResource has always seemed the poor cousin of the Rails world to >> me and I've never used it. Does anyone? Is it worth looking into? Know >> of any ActiveResource success (or failure) stories? >> >> -- James Healy <[email protected]> Fri, 02 Oct 2009 12:13:48 +1000 >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
