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


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

Reply via email to