[wp-trac] [WordPress Trac] #32470: Abstracting the Widget Classes
noreply at wordpress.org
Mon Jun 1 22:42:38 UTC 2015
#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 has-patch | Focuses:
Comment (by jacobsantos):
Replying to [comment:18 jdgrimes]:
> Replying to [comment:17 jacobsantos]:
> I have to admit that I'm not familiar with using interfaces, so I'm not
sure what the benefits are here. Maybe you could explain? To me it just
looks like added layers of complexity without actually reducing the
bootstrap code plugin devs have to write.
Right. So I think it will become more clear in a later patch when I
actually use the interfaces as opposed to just abstracting out some of the
I'm not sure what layers of complexity would be added. Can you explain a
little bit more what you don't understand? If it is just simply that you
don't think adding `implements` is useful, then yes, that should be more
clear in a later patch. I think that I'm going to remove some of the
changes to `WP_Widget` and just implement the correct interfaces. I am
going to still move some of the code out of the `WP_Widget`, but it will
be less of a concern than methods that could be replaced.
I'm going to create a new object that is going to just proxy or adapter
the implementation instead. This implementation will have what I wanted to
do with `WP_Widget` and remove the need to change `WP_Widget` except for a
few utility functions that will be moved to a separate class.
As for reducing the amount of code, that is something I will address. I'm
still attempting to comprehend the scope of the widgets and I'm still
breaking out the various parts of the `WP_Widget` class into discrete
parts. For the most part, I think the only change the default widgets will
have is that they won't extend `WP_Widget`, they will just implement
`WP_Widget_Display_EventInterface` and maybe `WP_Widget_AdminInterface`.
If it seems like every widget has majority of the methods, then I might
combine some interfaces. I just like to have small interfaces and
combining them into larger interfaces rather than have large interfaces
and try to break them out.
The goal is to see where common code exists and reuse interfaces wherever
possible, rather than have over broad interfaces.
The second purpose and far better reason to have interfaces is creating
unit tests. Interfaces allow for using dummies, fakes, stubs, and mocks.
By having smaller interfaces, you can create different test objects that
have specific purposes. So I can create a dummy that implements
`WP_Widget_AdminInterface` that doesn't do anything. Or create fakes that
don't write to the database, but store the changes where they can be
So while there is going to be quite a bit more code, the advantages will
be better tests. Also, the advantages will become far more apparent later
when plugin or theme developers start using the new interfaces. I do fear
that the knowledge base would perhaps add more frustration than benefit to
those who don't know how to properly use interfaces. I think those who are
more experienced will have an extremely fun time.
I think ultimately, the final implementation is going to add a lot more
code, but will also allow for much better unit and integration testing. I
also hope to change the system testing for widgets to better take
advantage of the changes.
The entire refactoring has to be taken together, I guess, and I hope you
understand once I have a more complete implementation.
> I think maybe what you envision and what @welcher was proposing are two
different things. I think you're leaning towards a complete rewrite of the
whole widgets API, while (I think) what @welcher was proposing was just a
little bit more abstraction/bootstrap in the `WP_Widget` class. I think we
need to be more specific about the scope of this ticket. I'm not saying
your scope is necessarily too broad, but I'm not sure that's what the
original intent was, and maybe these are sort of two different things that
should be separate tickets. ??
The scopes are definitely different, but both fit into this ticket. I
think certain parts of my patch could still be applied to this ticket as a
base for future tickets. My scope is that, improving `WP_Widget` should
extend beyond simply adding more methods. It should extend to better tests
and improved functionality. It is something that I wished I had done when
`WP_Widget` was first introduced. It has always been a flawed
implementation and my goal is to improve it to where it hopefully should
have been when it was first introduced.
Again, not so much a rewrite, because all of the existing code will still
be part of the implementation. If you do refactoring correctly, then you
don't rewrite something as move existing parts around to create something
that is hopefully better.
If it is the case that the patch scope is too broad, then I will create a
new ticket. I think it should still be possible to do what I need to do
without the code in this ticket's patch. I will still include it to show
the purpose of the changes.
Ticket URL: <https://core.trac.wordpress.org/ticket/32470#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac