i recommend you have a look at DHH's keynote at railsconf this year, where he describes a way of further embracing CRUD and viewing relationships as CRUDable "things" in their own right.
e.g. think of the user->group relationship as a CRUDable Membership model. suddenly the world becomes a much simpler place. Obviously, it doesn't make sense to seperate out all relationships as models, but in many cases, applications evolve such that we start needing to store metadata about what was once a simple relationship (e.g. .... when did that user join the group? who added them? at what date does the membership expire?) Video (embedded) http://blog.scribestudio.com/articles/2006/07/09/david-heinemeier-hansson-railsconf-2006-keynote-address Slides (PDF) http://www.loudthinking.com/lt-files/worldofresources.pdf On 8/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hey henthoca, > > Thanks for your posts, I pretty much understand your explanations and > I'll let you know how I get on. > > Ryno > > henthoca wrote: > > > Whoops, I forgot to mention that each other model should have a hasMany > > relation with the JoinModel, and the JoinModel should belongTo each of > > the other three models. I think I might have implied that, but better > > to explicitly come out and say it. > > > > I think this method would ideally allow for an n-way join table, not > > limited to 2 like the HABTM relations are. > > > > henthoca wrote: > > > I had ran into this situation a while back, trying to figure out how to > > > do a three-way join table. I believe gwoo helped me figure out that it > > > was best to create an extra model that belonged to the other three > > > models, instead of trying to do crazy HABTM join querys. > > > > > > My three models were Resources (rooms), Users and Groups (permissions). > > > Each user has a certain set of permissions per resource. Eg, User A is > > > an Teacher for Room A and a Student for Room B. Then I made an extra > > > model ( I named mine GroupsResourcesUser ) to store just the primary > > > id's of each of the other three tables, and set all of those as the > > > primary key in my new table. > > > > > > This method lets you pick one side and see which other sides it has, > > > like pick a User and see for which Projects the User has each Role, or > > > pick a Project to see which Users have each Role for that Project, or > > > pick a Role to see which Users have that Role for each Project. > > > > > > For example, finding the Project-Role combinations for a particular > > > (maybe logged in) user, I'd set $this->User->recursive = 3; and just > > > use $this->User->findById($id); to get the data. It'll be in the form, > > > $data['JoinModelName']['TargetModel1'] etc, so you should be able to > > > capture the relationships that way. > > > > > > It seems to work well enough for me. LMK if I need to explain it better > > > though. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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/cake-php -~----------~----~----~----~------~----~------~--~---
