[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