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

WordPress Trac wp-trac at lists.automattic.com
Tue Mar 23 07:45:23 UTC 2010


#12354: WP_WidgetArea class
-------------------------+--------------------------------------------------
 Reporter:  jimisaacs    |       Owner:  scribu              
     Type:  enhancement  |      Status:  new                 
 Priority:  normal       |   Milestone:  Future Release      
Component:  Widgets      |     Version:                      
 Severity:  normal       |    Keywords:  widgets dev-feedback
-------------------------+--------------------------------------------------

Comment(by jimisaacs):

 Just wanted to give an update... sorry for the long comment.

 I've been exploring a lot of possibilities with widgets in general; what
 they are, what they do, and what they should be.

 I have come to the conclusion that they are UI specific of course, and
 hence also PHP specific. This means I am starting to really wonder if they
 deserve any sort of data structure within the database, and instead take
 on a more modular PHP hierarchy. I have been contemplating this because I
 really hate having to make unnecessary database calls for hundreds of
 widget options when they might not even be used on the page, while on the
 other hand the widget might be rendered anywhere at anytime within any
 URL.

 Having all this brainstormed, I am going to try to implement this modular
 structure into my plugin first, before I actually propose it for the core.
 Better to test there anyway to actually see if it is an architecture worth
 pursuing.

 What I am going to do is make widgets into modules. These will be
 represented as directories in specific, though any number of locations.
 The widget load locations, is the base of plugin hooks being that a dev
 can hook into an modify where widgets are located and loaded from. Within
 these locations will be directories matching what is now the id_base of
 the widget hence identifying the module. Within each one of these
 directories will be a common structure for all widgets following the MVC
 pattern, so essentially overall widgets will become a UI only based HMVC
 implementation.

 I haven't decided entirely on the inner directory structure. What I've got
 so far is a conf/ directory, models/ directory, controllers/ directory,
 and views/ directory. Within the conf/ directory will be config PHP files
 that are nothing more than files of arrays. I haven't decided if these
 files will return their values directly as a function value or define
 their arrays explicitly and be loaded by a reference to their variable
 names. The models/ directory may be the same as the conf/ directory
 defining the fields or settings of the widget, or a class to modify and
 define them. The controllers/ directory would be a place to store more
 complicated functionality of the widget, but right now I was only thinking
 of it as the place to store the actual widget class itself which in this
 architecture would be the only bridge from the module to the widget API as
 a whole. The views/ directory is pretty self explanatory, but I did think
 it would need to contain 2 view PHP files at minimum, a default.php view
 for the front-end, and an admin.php view for the controls in the backend.
 Of course more views depending on the complicated nature of the widget
 could be added, but these views are the minimum needed for a widget's UI.

 So overall what does this accomplish? First off, it negates the complete
 necessity of saving every single thing about a widget in the database
 because it provides an organized file structure where simple PHP array
 scripts may be saved and edited with ease. This opens the widget API up to
 more customizations and understanding. It also defines an explicit
 structure for developers to follow while allowing their plugins to be much
 more accessible to other developers... and so on.

 Well this is where my thought process has taken me on this brainstorm.
 I'll continue working it out.

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


More information about the wp-trac mailing list