Universal Component Class Concept

[johnjamesjacoby]

Idea on how to better handle BuddyPress component creation.

[johnjamesjacoby]

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]

Universal Component Class

[apeatling]

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?

[DJPaul]

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.

[johnjamesjacoby]

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.

[MrMaz]

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!

[wpmuguru]

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.

[johnjamesjacoby]

Changing ownership to myself for future review in 1.3.

[r-a-y]

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

Proposal to close?

[DJPaul]

Implemented by jjj in r3751