search

WebDevStudios / oops-wp

A collection of abstract classes, interfaces, and traits to promote object-oriented programming practices in WordPress.
57 stars 9 forks source link

Add abstract data structure for metabox registration #16

Open jmichaelward opened 5 years ago

jmichaelward commented 5 years ago

We're looking to establish an abstract class that provides an interface for quickly defining and registering a custom metabox with WordPress.

jmichaelward commented 5 years ago

Assigning this over to @tommcfarlin, as he has done some preliminary work on a client project that could lead to the completion of this ticket.

jmichaelward commented 4 years ago

There are now two PRs for this: #18 and #25, the latter of which was forked from the former, and has been refactored a bit to match the structure of other elements from within the library.

tfrommen commented 4 years ago

@jmichaelward I don't know if you know abot this, but I strongly recommend checking out MetaboxOrchestra, especially when working on a more complex and Composer-based website build.

In my opinion, there is no such thing as a single thing to handle meta box registration. Or, there is, but that would be a God class, bringing no more than a pseudo namespace for all the procedural code that exists in WordPress.

jmichaelward commented 4 years ago

@tfrommen Thank you for sharing that library, and for taking a look into this one!

My goal for the OOPS-WP library is to provide a set of classes that help engineers quickly scaffold up WordPress structures as objects, and hopefully help move them along the path to better understand when and how to separate logic into additional objects. This is (hopefully) achieved by being lightly-opinionated about implementation, providing feedback via exceptions when requirements are missing, establishing sensible and minimal defaults, and providing enough flexibility that the developer can fully determine the rest of the implementation.

You'll note that none of the abstract class structures in OOPS-WP define any constructors, in part because I want to offer engineers full control over whether they'd like to define their models within the classes themselves or via external objects that instantiate them and subsequently pass in a configuration.

Metaboxes are, of course, much more dynamic entities that can have multiple different levels of complexity. I agree that developers should not create god classes, but would argue that registration is just a part of the overall hierarchy of a Metabox entity. MetaboxOrchestra looks like a great library to split up those disparate parts of a Metabox's responsibility, one that could be a standalone part of a given plugin or could live in concert with the abstract Metabox structure I've proposed in PR #25.