[wp-trac] [WordPress Trac] #32470: Abstracting the Widget Classes

[WordPress Trac]

#32470: Abstracting the Widget Classes
--------------------------+------------------------------
 Reporter:  welcher       |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+------------------------------

Comment (by jdgrimes):

 Replying to [comment:9 welcher]:
 > Replying to [comment:8 jdgrimes]:
 > > I've done something similar to this with the base widget class in one
 of my plugins.
 >
 > Have you run into any situations where that is limiting?
 >
 > I like the idea of building out WP_Widget so that child classes contain
 the smallest amount of code needed - essentially just the changes/new
 functionality - but if the user is constantly having to override 3 smaller
 methods instead of one large one, we're not really that much further
 ahead.
 >
 > Thoughts?

 I have just implemented this recently, but so far I have had no reason to
 override anything but the `widget_markup()` method (though in this case it
 is called `widget_body()`). I think that probably in 90% of cases that's
 the only one that would need to be overridden. But if the user needed to,
 they could always just override the `widget()` method as a whole in the
 traditional manner.

 If you'd like to take a closer look at what I've done, here is a
 [https://github.com/WordPoints/wordpoints/blob/master/src/includes/class-
 widget.php link to the plugin's main widget class], and another to
 [https://github.com/WordPoints/wordpoints/blob/master/src/components/points/includes/widgets.php
 the code for the plugin's widgets].

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32470#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform