Skip to:
Content
Pages
Categories
Search
Top
Bottom

Switching from “groups” to a “object” API

  • Profile photo of dennissmolek
    dennissmolek
    Participant

    @dennissmolek

    I have been pouring over the site trying to catch up from when I took a break about 10 months ago. The only thing I notice is Andy is confirmed gone as he’s working on Jetpack now. I’ve read through the dev-chat logs and the trac and got fairly caught up.

    I have two projects that I’m working on right now. One is for the AIGA of my University, the other is a personal idea, both based on a sort of social site. I have a few ideas that I want to get into the site, and instead of writing tons of plugins and hacks to get BP to do what I want I’ve decided I’m just going to take the groups object and build off of it on a case by case basis. Object Oriented BP in a way.

    Starting with the group object we have a vast API and framework to build from. Not to mention when you add plugins like Group Docs, BP Albums, Bbpress, ETC. These make groups the strongest element on any BP based site. Stronger even than the individual user. Here are some sections I think could use the “groups” as its base and how I will be attempting my sites. Firstly, I am simply adding meta data for the groups to tell them what “type” of group I’ve created.

    Users:
    Strips all other members roles and ability besides admin, in this case the user.
    Changes “members” to “peers(friends)”. This allows me to categorize other users into “roles” of the group. Such as coworker, family, acquaintance, etc.
    Port Messages function here. Messages functions seems to be the only thing missing from the groups object.
    Albums- Uses same structure as currently used by BP Albums. Or whatever plugin you want.
    @mentions- Although personally not important, the fact that groups arnt already able to do this is weird.
    Groups: Yes users can join other groups. So now groups can join other groups. Moderators can be in Admins, Admins in users. Yay OOP
    Almost all other functions are the exact same for a user or a group.

    Groups:
    Nothing changes, except they can now be in other groups, and have sub groups.

    Events:
    A event is simply a group with a date. I dont see on a facebook event what the difference is. There are three roles of group members – Attending, Maybe, and Not Attending. Has albums, has a feed. Its a group.
    Because groups can be in other groups, A event can be owned by any group or user.

    Then I have things like competitions, which are simply built off of the group object. A simple plugin would just add a new subset from the parent object and we are rolling.

    I think this would be a much easier way to work. We have ONE object to update and modify. Plugin developers simple add to/ remove parts of the object. It’s already in place, its already strong, and does all the things we need it to. Forums are attached to groups so that means Events or Competitions or whatever could ALREADY have forums. Can my event have a twitter feed? Sure, groups already do. Can I set my personal privacy? Sure, groups have more built in here on what to hide or show. What about activity? Groups already stream just as much as users.

    It just seems so stupid for everyone to be adding features and new objects so every BP install is so insanely different from the next that it takes “experts” to figure out all the plugins and crap on each one.

    The only issue I see is backpat. I mean, I think a update script wouldnt be to bad, but would be a bunch of work. My sites are both ground ups so I’m not too stressed.

    I just want some opinions on this. Mostly I’m trying to find someone to say why its a bad idea.. I half thought of just starting totally over with a central object and building a new plugin, but this one is so close to perfect. So please, weigh in, even if you hate the idea..

    -Dennis

Viewing 5 replies - 1 through 5 (of 5 total)
  • Be sure to check out BuddyPress trunk. The components have a -loader.php file which extends from a BP component class; it might help you achieve this.

    Profile photo of dennissmolek
    dennissmolek
    Participant

    @dennissmolek

    Thank you Paul! I’m going through it now, on the trunk its bp-core-component.php

    Profile photo of dennissmolek
    dennissmolek
    Participant

    @dennissmolek

    So I have been reading through the code from the trunk and it seems I hadn’t read the code like I should have. The code is already built around the component class, but ALL components are. From what I have been reading I am simply wanting to extend the BP_Groups_Component to fulfill my individual needs. Somethings I wish were different but I dont want to reinvent the wheel.

    Let us know how it works out. I haven’t tried that myself yet, and the component classes are/will be new to 1.3, so if you find any implementation difficulty, now’s the time to report it :)

    Profile photo of dennissmolek
    dennissmolek
    Participant

    @dennissmolek

    It’s exciting to see! Last time I was messing with the code it wasn’t so well documented throughout and I’m excited to see the component class. Out of curiosity, why isn’t that stuff in the codex? Time? I’d be willing to put some of it in there..

    The only thing I see as an issue right now is filtering out the subclasses from the parents. IE events from groups. I’ll have to setup exclusionary functions… Not a big deal but something I’ll have to deal with.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.