[buddypress-trac] [BuddyPress] #1479: Universal Component Class Concept

[buddypress-trac at lists.automattic.com]

#1479: Universal Component Class Concept
----------------------------+-----------------------------------------------
Reporter:  johnjamesjacoby  |       Owner:                
    Type:  enhancement      |      Status:  new           
Priority:  minor            |   Milestone:  Future Release
Keywords:  needs-feedback   |  
----------------------------+-----------------------------------------------

Comment(by 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 [http://us.php.net/functions
 .variable-functions variable functions] to help simplify the creation and
 execution of those functions.
 Deprecating code again will be dizzying for anyone who's paying attention.

-- 
Ticket URL: <http://trac.buddypress.org/ticket/1479#comment:4>
BuddyPress <http://buddypress.org/>
BuddyPress