[wp-trac] [WordPress Trac] #12354: WP_WidgetArea class

WordPress Trac wp-trac at lists.automattic.com
Tue Feb 23 22:02:49 UTC 2010


#12354: WP_WidgetArea class
-------------------------+--------------------------------------------------
 Reporter:  jimisaacs    |       Owner:  scribu              
     Type:  enhancement  |      Status:  new                 
 Priority:  normal       |   Milestone:  3.0                 
Component:  Widgets      |     Version:                      
 Severity:  normal       |    Keywords:  widgets dev-feedback
-------------------------+--------------------------------------------------
 After a short discussion involving the state of the Widget API within
 another ticket's comments, it was proposed to me to create new ticket on
 this subject.

 The idea is that in updating the Widget API, like the WP_Widget class,
 widget areas will have a similar registry structure.

 In my opinion though, I believe that for backwards compatibility it should
 be integrated but remain separate from the current API for controlling
 sidebars, also like the WP_Widget class.

 In the previous discussion, I said that a possibility could be creating a
 WP_WidgetArea class, and a WP_WidgetArea_Factory class to register and
 unregister them.

 After some thought though, I believe this is pretty much unnecessary.

 What is a widget? - It is a GUI module with a client-side and
 administrative view, wrapping how to control, use, and display data.

 It is a form of MVC, and that's basically it! That being realized, I don't
 see a problem with adding one more default widget to the core:

 WP_WidgetArea extends WP_Widget

 This will allow dynamic generation of widget areas. Implementing how to
 edit these areas within the current interface is another story, though I
 have a kind of hacked logic I am unhappy with working in a released plugin
 of mine.

 In the future, using widgets for widget areas will eventually depreciate
 the entire sidebar API. It would only depend on one global area to add and
 pull widgets from (the theme... cough...).

 Also, with custom post types now becoming more prevalent, and this is just
 my imagination talking, widgets could become another form of the post
 object:

 post_type = widget

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12354>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list