Replies: 4 comments 4 replies
-
Thanks for offering this discussion and for continuing (I hope) the fork of WordPress-Plugin-Boilerplate. I've invested some time reviewing the code and have a few design-type questions. I'm trying to understand to what degree some of the choices are just "because that's the way it's been for a long time" vs. those that have strong rationales behind them. (I'm a long-term programmer, but have only been doing WordPress stuff--among many other things--for the last couple of years. So I'm not so arrogant as to think that I know the best way to accomplish something in WordPress.) Anyway, here goes:
Thanks for you help in clarifying this stuff. Scott M. |
Beta Was this translation helpful? Give feedback.
-
Hi @LoonSongSoftware and welcome! Related to the 3 points you outline, let me reply one by one and hope I can shed some light in these doubts. I am pretty sure about 1 and 2, but #3 I am not entirely sure I got it right.
Thanks for initiating a discussion ;) Thanks for your input and let me know if any doubts come up or something is not clear! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick reply.
1: I get it. I didn’t mean to imply that is_admin() was the only (or best) way to go. I was more asking about the boilerplate’s default of loading both/everything with every page display.
2: Ditto. Thanks.
3: Your explanation makes sense (and I recognize the history of the code). I can see the benefit of seeing all of the WordPress hooks in the base plugin class. Personally, though, I prefer to keep them encapsulated within the relevant classes on the theory that it improves the “object”-ness of the classes—expose a streamlined public interface and keep the execution guts in a single (class) file. Both approaches have their advantages and disadvantages.
Thanks again!
|
Beta Was this translation helpful? Give feedback.
-
Since this is a “discussion” area, I’ll respond.
I agree in general with @nylen; mostly, I was looking to understand the philosophy of the boilerplate, so I could figure out which comments would be considered improvements vs. those that would be entirely personal preferences.
On the subject of “single-use classes,” I find them useful for a couple of reasons:
1. They provide a structure to encapsulate pretty much all of the functionality related to a section of code, so users (or those with short memories) only need to focus on the ‘public’ members for an otherwise-working class. Personally, I’d rather manage five classes, each with 10 public functions and 10 private ones rather than a monolithic file (or files) with 100 functions. But I recognize that that’s a personal preference.
2. By splitting up the code into classes, it becomes relatively easy to turn features on and off to improve efficiency and site responsiveness. If it’s clear from the WordPress environment that one or more big chunks of code aren’t needed, why not skip the ‘includes’ of the related files and execution of the class constructors? Especially when the constructor is resource (CPU, DB access, filesystem) intensive).
I don’t think classes should be used “for all and everything,” but I do tend to rely on them to break down complex code into its component parts for the reasons given above.
I think a wiki would be a great idea, and I’d be happy to help.
Scott
|
Beta Was this translation helpful? Give feedback.
-
This was originally the introduction Discussion, however since the thread discusses design and architecture the introduction thread has been moved to #15
Beta Was this translation helpful? Give feedback.
All reactions