Maybe what you want is a Profile object, a User object, and a Group object. Profile would contain the stuff shared by both, so a User and a Group would both have a profile, but a Group wouldn't have a birthday, like a user would.
Make sense? On Thu, Nov 20, 2008 at 10:23 PM, Levi Rosol <[EMAIL PROTECTED]> wrote: > Decisions decisions decisions. Bruno, the way you describe was my initial > plan (independent m/v/c's). I wanted to build it in such a way so that it > could be added to the CE core easily, but on the same hand, for my purposes, > the base functionality of a group will be nearly the same as a user. However > I will be extending it tremendously as the Group object is really what my > application will be built around. > > Also, I don't see myself building it as a plug-in for CE. My application > consists of CE as it's base, and my custom stuff on top of it. I would > prefer CE to be the app, not the plugin, but it does function the way it is. > I don't want to burry my stuff in the plug-in though. > > Based on the reading i've done, I think a clean line of separation can be > kept by taking the STI approach. Basically add a 'type' field to the User > model, then go from there. It may even be worth while to abstract out the > base functionality that both models will share, and inherit from that for > both User and Group. > > Then comes the question of Group membership. In my scenario, Users have > friends and groups have members. If two Users are members of the same Group, > they would be colleagues. When a User views another Users profile, they > would see the Users friends as you already have them, and would have a > separate box for colleagues. That not exactly how it would work, but it gets > the idea across that colleagues are different than friends. > > So that could involve inheriting from the Friendship model for the Member > model. And I guess in that case, it may make more sense to have a separate, > clean cut Group as all of the friendship stuff in the current User model is > null and void for a Group. > > I'm starting to ramble again. Is this making sense? > > I think I'm to the point to where I just need to jump in and do it, and if > it can be re-used in CE great. Either approach can be added to CE. It just > depends on how much refactoring someone is willing to do to get it in there. > > -- > Levi Rosol > > Twitter: @LeviRosol <http://www.twitter.com/LeviRosol> > > > > > On Thu, Nov 20, 2008 at 12:53 PM, Bruno Bornsztein < > [EMAIL PROTECTED]> wrote: > >> Hey guys, just wanted to weigh in: >> >> I'm not a fan of implementing Groups by doing inheritance/user_type on the >> User model, since they're essentially different objects, IMO. So I doubt >> this kind of implementation would be accepted back into CE (if submitted). >> I'd much prefer a new Group model with its own logic and views. >> >> In fact, I'd suggest doing this as a CE plugin (basically, a plugin that >> relies on Engines and CE, implementing groups functionality). The plugin >> could have its own migrations, models, controllers and views, and just come >> with the requirement that you have CE installed as well. That way we can >> work out the kinks and then hopefully integrate it into the core. >> >> Thanks, and good luck. >> Bruno >> >> >> On Wed, Nov 19, 2008 at 10:58 PM, sachin kale <[EMAIL PROTECTED]>wrote: >> >>> >>> >>> On Thu, Nov 20, 2008 at 10:11 AM, Levi Rosol <[EMAIL PROTECTED]>wrote: >>> >>>> Ok, that makes sense. If I'm understanding you correctly, you're >>>> basically talking about Single Table Inheritance ( >>>> http://wiki.rubyonrails.org/rails/pages/singletableinheritance). >>>> >>> I haven't read that and really don't know what it means. >>> >>>> >>>> So then to define some sort of ownership of a group, you'd simply add >>>> some sort of FK to the User model, like Manager_User_Id ? I suppose >>>> though, >>>> in my case though, I'd have a cross ref table because we will need the >>>> ability to have more than one manager for a group, and a single user could >>>> manage more than one group. >>>> >>>> has_many :groups, :through => :user_group >>>> >>>> But then what about a role based system? ie: manager, moderator, etc I'd >>>> want to keep that functionality separate from the current user/role setup >>>> because a single user may manage multiple groups. >>>> >>> >>> You can keep group-moderatorship as different model , similar to forum >>> moderatorship, which addresses requirement of user managing multiple groups. >>> This separates it from group-membership. >>> I haven't done this, as my groups requirement did not had >>> user-created/moderated groups but they were fixed groups having only user- >>> memberships. >>> >>> >>>> Sorry, I'm rambling on here. Clearly I need to spend some more time >>>> defining the functionality I need before moving forward. :-) >>>> >>>> >>>> On Wed, Nov 19, 2008 at 10:09 PM, sachin kale <[EMAIL PROTECTED]>wrote: >>>> >>>>> You can do that, cut off all the photo functionality from views (show >>>>> method of user, photos) >>>>> >>>>> For convenience you can add user_type to user model , this will have >>>>> value "group" for group. >>>>> Based on this user.user_type you can decide what functionality should >>>>> be provided. >>>>> >>>>> Or write a :before_filter , like - "usertype_user_required" in that >>>>> filter you can check for user_type. >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Nov 20, 2008 at 9:32 AM, Levi Rosol <[EMAIL PROTECTED]>wrote: >>>>> >>>>>> Will that allow a User and a Group to have different functionality if >>>>>> required? for example, lets say you didn't want a group to have a Photo >>>>>> Gallery. >>>>>> >>>>>> Levi Rosol >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 19, 2008 at 9:54 PM, sachin kale <[EMAIL PROTECTED]>wrote: >>>>>> >>>>>>> I have implemented projecting a group as a 'user' >>>>>>> You can have a seperate model for relationship between group and >>>>>>> subscribers -> membership, which has group_id(i.e user_id projected as >>>>>>> group) and user_id(subscriber to the group) >>>>>>> This way we can have all the features for the group that are >>>>>>> available to user. >>>>>>> like group blog/photos/comments/home-page etc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 20, 2008 at 8:57 AM, Levi Rosol <[EMAIL PROTECTED]>wrote: >>>>>>> >>>>>>>> >>>>>>>> So one of the next steps I need to take with CE is to implement some >>>>>>>> sort of Group functionality. The idea is that any user can create a >>>>>>>> Group. A Group will have nearly all of the same functionality that a >>>>>>>> User has in terms of a profile, comments, photos, friends (but >>>>>>>> called >>>>>>>> members), etc.. >>>>>>>> >>>>>>>> What are your thoughts on the best way to approach building this? I >>>>>>>> think because of how tightly everything is tied to the existing >>>>>>>> User, >>>>>>>> the only route to go with this is to create a new model from scratch >>>>>>>> and do a lot of copy/pasting to bring over the existing User >>>>>>>> functionality. >>>>>>>> >>>>>>>> Got a better way? Cause this doesn't seem very DRY. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sachin Kale >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sachin Kale >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Sachin Kale >>> >>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CommunityEngine" 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/communityengine?hl=en -~----------~----~----~----~------~----~------~--~---
