Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 11 years ago

Last modified 5 years ago

#1479 closed enhancement (fixed)

Universal Component Class Concept

Reported by: johnjamesjacoby Owned by: johnjamesjacoby
Milestone: 1.5 Priority: minor
Severity: Version: 1.5
Component: Core Keywords: close
Cc: marshall.sorenson@…, windhamdavid

Description

Idea on how to better handle BuddyPress component creation.

Attachments (1)

bp-component.php (6.8 KB) - added by johnjamesjacoby 12 years ago.
Universal Component Class

Download all attachments as: .zip

Change History (13)

#1 @johnjamesjacoby
12 years ago

The idea behind this is components can be easily created using a fundamental set of functions with a similar structure. If a component requires more than this class offers, it can be subclassed and new functionality can be introduced in the new classes.

Thoughts?

@johnjamesjacoby
12 years ago

Universal Component Class

#2 @apeatling
12 years ago

What you're really building here is an extension API not unlike the group extension API in 1.1. What do you think advantages and disadvantages of designing something like this are?

#3 @DJPaul
12 years ago

I think John's proposing this to reduce unnecessary code duplication and to remove some of the common "plumbing" that each Component has. It's not really the same sort of API that the groups have. The closest structure that WordPress has to BuddyPress' Components is its Widgets and Theme system.

The sample class John's attached needs some iteration but I think it is a solid idea.

#4 @johnjamesjacoby
12 years ago

Similar to the groups API, yes, but it will also standardize BuddyPress component creation. This has pros and cons.

A big one (both pro and con in my mind) is it will force people to adapt their custom components to working in an exact and precise fashion with core-formed actions and filters. But, they can always create their own too.


Pros
Reduce code duplication. All components must go through these motions anyhow to be born into the world.
Make it easier for new components to be introduced by giving plugin authors an API to extend, rather than a skeleton component to mimic.
Since all components would go through a standard verification procedure, all of their initial function names and actions follow the same nomenclature, making it easier to remember which functions are responsible for what tasks. (Less dev memorization, let the computer do the work)
Looping through all components can now be an exact science, as all core variables are guaranteed to have the same base variables in place.
Plugin authors now have a direct way to 'plugin' to the BuddyPress core platform without needing to attach their own code to the $bp global; this will do it for them.
Faster component development and easier refactoring of all components as platform evolves. This is my favorite reason to do this. BuddyPress is such a rapidly evolving platform, and keeping up with changes across several individual plugins is challenging. This core component class would simplify those changes in one central location rather than 6 separate ones.
Deprecating code to fall back to this method shouldn't be too hard.
Components can now be subclassed and individually extended to introduce new functionality into each of them, not unlike the group API but for all components.
More red in the trac. :D

Cons
Forced functions and action names. People may not immediately like being required to do things a certain way. I think WordPress is as popular as it is, because you can jump in and do things however you want and still get the job done. This idea goes against that grain.
It re-introduces a little OOP into an otherwise OOP'less world.
It does not address any template-tag functions that components would have. For that I would propose something like variable functions to help simplify the creation and execution of those functions.
Deprecating code again will be dizzying for anyone who's paying attention.

#5 @MrMaz
12 years ago

I think this is a good start. I would want to take it much further and get all crazy OO, and stick really tight to a pattern like Template Method that can be used to introduce a lot more control over data formatting/filtering/security.

That would look more something like this:

// in base component class
function get_slug() {
    if ( preg_match('/[a-z0-9]/', $this->my_slug() ) ) {
        return $this->my_slug();
    } else {
        die('your slug is no good');
    }
}

// in child component class
function my_slug() {
    return 'appname';
}

All of the base component methods would only call get_slug(), so it would not be possible for anyone to mess things up. Notice there are no variables used, so it wouldn't be possible for someone to modify the slug from the outside.

And just in general, I think global data is crazy bad, so any opportunity to do away with it should be taken advantage of.

Most of this flies in the face of how WP handles just about everything, so I am not expecting anyone to warm up to this very much. I will say though, that it would be smart to use this overhaul to implement some encapsulation of the core functionality and global data, because right now anyone can fark with any data they want to. They can just up and change the slug for a component!

#6 @MrMaz
12 years ago

  • Cc marshall.sorenson@… added

#7 @wpmuguru
12 years ago

That's the general idea I had in my last post in the forum thread. In the example at the top you are sort of setting the precedent of using the component instead of extending it with a component specific class.

#8 @johnjamesjacoby
12 years ago

  • Component set to Core
  • Owner set to johnjamesjacoby
  • Status changed from new to assigned

Changing ownership to myself for future review in 1.3.

#9 @windhamdavid
11 years ago

  • Cc windhamdavid added

#10 @r-a-y
11 years ago

  • Keywords close added; needs-feedback removed
  • Type changed from enhancement to task
  • Version set to 1.3

Looks like this is already implemented in BP 1.3-bleeding.

Proposal to close?

#11 @DJPaul
11 years ago

  • Milestone changed from Future Release to 1.3
  • Resolution set to fixed
  • Status changed from assigned to closed

Implemented by jjj in r3751

#12 @DJPaul
5 years ago

  • Type changed from task to enhancement
Note: See TracTickets for help on using tickets.