All, This is will be a bit long winded but here goes... I am working on a medical records application that will provide a web interface (HTML) and REST web services. The application supports many users and many facilities (clinics, hospitals, etc,). A user can belong to more than one facility and have a different set of permissions at each facility. So far I have modified the restful authentication and restful acl plugins to deal with a current user and current facility context. In a web application a simple drop list of facilities that user can access is enough to change the current facility context of that user. As I was considering the REST interface to the application, I decided that it would be to cumbersome for a user to call a resource to change their current facility (not RESTful?). Instead I am kicking around the possibility of using nested resources. When a user accesses http://localhost/facility/2/patients, I change the current facility context based on the URI. I tested the idea and it works. I am concerned that it may get too complex with URIs such as /facility/ 2/patient/123/vitalstatistics (although it makes perfect sense to me). I have a number of articles expressing the nesting should not go beyond 1 level. 1. Would it make more sense to have a URI to change the facility context or extract it from a normal resource URI e.g. /facility/2/ patient/3? 2. In the case of nesting, would it be acceptable to use more than one level in this scenario? 3. When modifying controllers to work in a nested configuration (easy enough), what is the recommended way of constructing filters to handle complex relationships. For example: user profiles, facilities and patients all have a state and country code (multiple foreign key relationships). My guess is that this could get ugly in very quickly. Most examples show only simple one-to-many relationships when it comes to nesting. If anyone has done something similar before and can offer any insight, it would be greatly appreciated. Even a pointer to an existing code base would be enough. Thanks in advance, Keith --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 20, 7:39 am, KRD <KEITH.DA...-LGkX7t1rY7B+cjeuK/JdrQ@public.gmane.org> wrote:> All, > > This is will be a bit long winded but here goes... > > I am working on a medical records application that will provide a web > interface (HTML) and REST web services. The application supports many > users and many facilities (clinics, hospitals, etc,). A user can > belong to more than one facility and have a different set of > permissions at each facility. > > So far I have modified the restful authentication and restful acl > plugins to deal with a current user and current facility context. In > a web application a simple drop list of facilities that user can > access is enough to change the current facility context of that user. > > As I was considering the REST interface to the application, I decided > that it would be to cumbersome for a user to call a resource to change > their current facility (not RESTful?). Instead I am kicking around the > possibility of using nested resources. When a user accesseshttp://localhost/facility/2/patients, I change the current facility > context based on the URI. I tested the idea and it works. > > I am concerned that it may get too complex with URIs such as /facility/ > 2/patient/123/vitalstatistics (although it makes perfect sense to > me). I have a number of articles expressing the nesting should not go > beyond 1 level. >I wonder if you''re not missing a model here, something that represents the patient-at-a-facility combination. I''m not sure what it would be called, let''s just call it a "registration" for now, something that scope''s a patient''s data to a particular facility. Then you''d have URLs like: /registrations/123/vitals You''d still have /facilities and /patients for the "master" lists of each, but a specific patient-facility combination would be represented by a registration record (i.e., on the model side, facility has_many :patients :through => :registrations). A Registrations controller could then be a simple RESTful interface on top of that. Does that help? Jeff purpleworkshops.com switchingtorails.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks, Sort of... the reason I want to nest ''encounters'' under facilities (I would have a facility has_many :encounters :through => :registrations, I am still at the conceptual stage) is so I can extract the facility id and set the current facility context for security purposes, much like the concept of a current user. I didn''t want to make the user call a separate URI in order to do this. Are you suggesting that I could get the "encounter" first and then use the model association to get the facility? If so didn''t think of that :-) although that would mess with the way restful_acl works. Thanks for taking the time to answer as I worded my question in a not so succinct manner! Keith --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---