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 <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 -~----------~----~----~----~------~----~------~--~---
