eeekkk!!! config file! noooo! :-p no, but seriously, I like the idea of a profile, but maybe it makes sense to flip the functionality. User is the root object, has the basics like account info, then the Profile object has all of the other stuff like birthday, forum moderation, photos, etc.
The only problem i see there is that a group wouldn't have authentication. I would login as myself (a user with a profile) and i would manage the Groups i've created. I would never log in as the Group itself. So maybe User gets stripped down to bare bones, and then a user can have one Profile and many Groups tied to it. When i first started building my application, this is what I did (although i hadn't built the Group yet) and it seemed like it was going to work well. Esentually all the User model had was username, password (salt, etc) and email. all other data, including forum moderation, photos, friends, etc. were associated to the Profile, not the user. This would allow then for Groups to be tied to the User via User_Group and that cross ref could hold additional values like roles and what not. I think this is a good discussion, but now i'm wondering, who's gonna make the call as to what gets done and how to CE? I'd love to contribute, but bare in mind, I'm a RoR noob, and am not confident enough to tackle this myself (that, and i don't understand the whole plugin concept). Where can I help? What's the first step? -- Levi Rosol Twitter: @LeviRosol <www.twitter.com/LeviRosol> On Thu, Nov 20, 2008 at 10:52 PM, sachin kale <[EMAIL PROTECTED]> wrote: > That makes sense, > That would be a good addition to CE. > > Also going further if it makes sense and is viable, I think we can have all > the functionality attached to profile object like - > photos/forums/blogs/friendship etc > > For group, we can select forum/photos/(membership - friendship model - > renamed in the view) etc > For user - photos/comments/blog/friendship etc. > > The functionality selection for group/user can be decided from a config > file. I am aware this would be huge task though but this would result in > more flexibility. > > > > > On Fri, Nov 21, 2008 at 10:09 AM, Bruno Bornsztein < > [EMAIL PROTECTED]> wrote: > >> 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. >>> >>> >>> >>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
