id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
12354	WP_WidgetArea class	jimisaacs		"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"	enhancement	assigned	normal	Future Release	Widgets		normal		widgets dev-feedback	Denis-de-Bernardy rspindel