[wp-trac] [WordPress Trac] #28216: Allow to register pre-instantiated widgets

[WordPress Trac]

#28216: Allow to register pre-instantiated widgets
-------------------------------+------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Widgets            |     Version:  3.9.1
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by mdwheele):

 Replying to [comment:9 westonruter]:
 > OK, I don't have any problem with the proposed change. Can you put
 together a patch, including unit tests?

 If it's not against contribution standards for me to do so, I can prepare
 a patch for this feature. I found this ticket in the process of looking to
 fix the same issue myself.

 To expand upon the use-case for this being made-available to core, I have
 an example:

 I maintain a set of microservices where I work that are responsible for
 serving HR and Student data as well as other use-cases. For this
 particular use-case, we have a service responsible for providing query
 capabilities for a University job-board. This is exposed as a JSON API and
 I have also written packages around that API for PHP-consumption. All this
 leads to... the implementation of a client that talks to that API conforms
 to a known interface and I want to make a WordPress widget that depends on
 that client interface to query the job board.

 The biggest reason for wanting DI support for things like Widgets is that
 I can treat the widgets as simple-wiring of my own services into
 WordPress. I treat Plugins exactly the same; simple-wiring of a domain
 model into WordPress. Therefore, when I test, my focus is on a WordPress-
 agnostic domain model. When I write integration tests with WordPress and
 my custom model, I'm making sure that when a widget is "booted" it calls
 the right methods on my services. I do not necessarily care to invoke my
 services as part of that test... I just want to have spies tell me if
 things aren't called as expected.

 This can certainly be achieved through setter-injection, but is more
 conventional to implement through constructor injection. More importantly,
 constructor injection FIRMLY declares that X widget wiring has a
 dependency on some service layer. Setting injection does not do so
 explicitly.

 '''Anywho...''' I typed all that out just to give a more in-depth use-case
 than we currently had. Also, I've made the changes to enable this and
 would GLADLY contribute upstream.. However, this would be my first
 contribution to core and I wanted to make sure it was cool for a sideline
 observer to send code for someone elses Trac ticket! :)

 Thanks all!

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