[wp-trac] [WordPress Trac] #30740: WP_Customize_Manager::register_control_type should also address registering JS subclasses

WordPress Trac noreply at wordpress.org
Wed Dec 17 09:35:03 UTC 2014


#30740: WP_Customize_Manager::register_control_type should also address registering
JS subclasses
------------------------------+-----------------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Future Release
Component:  Customize         |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  needs-patch       |     Focuses:
------------------------------+-----------------------------

Old description:

> There are a couple of steps required to leverage JS for custom Customizer
> controls. In addition to declaring the object, which is basically like
> subclassing in PHP, you have to extend the Customizer's
> `controlConstructor` with the subclass.
>
> It seems like `register_control_type()` could also take care of this (in
> addition to printing JS templates for controls), if we added an optional
> second argument for the JS class name. This would lower the barrier to
> creating new JS-heavy Customizer controls, and also make the somewhat
> annoying step of registering the control type more useful.
>
> Essentially, we would be introducing a mechanism to do this
> automatically:
> {{{
> /**
>  * Extends wp.customizer.controlConstructor with control constructors for
>  * menu_item, nav_menu, and new_menu.
>  */
> $.extend( api.controlConstructor, {
>         menu_item: api.Menus.MenuItemControl,
>         nav_menu: api.Menus.MenuControl,
>         new_menu: api.Menus.NewMenuControl
> });
> }}}

New description:

 There are a couple of steps required to leverage JS for custom Customizer
 controls. In addition to declaring the object, which is basically like
 subclassing in PHP, you have to extend the Customizer's
 `controlConstructor` with the subclass.

 It seems like `register_control_type()` could also take care of this (in
 addition to printing JS templates for controls), if we added an optional
 second argument for the JS class name. This would lower the barrier to
 creating new JS-heavy Customizer controls, and also make the somewhat
 annoying step of registering the control type more useful.

 Essentially, we would be introducing a mechanism to do this automatically:
 {{{#!js
 /**
  * Extends wp.customizer.controlConstructor with control constructors for
  * menu_item, nav_menu, and new_menu.
  */
 $.extend( api.controlConstructor, {
         menu_item: api.Menus.MenuItemControl,
         nav_menu: api.Menus.MenuControl,
         new_menu: api.Menus.NewMenuControl
 });
 }}}

--

Comment (by westonruter):

 Good idea.

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


More information about the wp-trac mailing list