[wp-trac] [WordPress Trac] #11517: Make Admin more MVC-like
WordPress Trac
wp-trac at lists.automattic.com
Thu Dec 31 17:28:38 UTC 2009
#11517: Make Admin more MVC-like
----------------------------+-----------------------------------------------
Reporter: filosofo | Owner: filosofo
Type: enhancement | Status: new
Priority: normal | Milestone: 3.0
Component: Administration | Version: 3.0
Severity: normal | Keywords: admin-theme
----------------------------+-----------------------------------------------
Changes (by jeremyclarke):
* cc: jer@… (added)
Comment:
I really like this idea in general and think its the right direction for
the admin going forward. It would have the effect of forcing core devs to
clean up their act when they add stuff, using/augmenting existing output
functions as needed and adding new ones when they are missing. Having the
core devs think of plugin authors when creating UI is good both so they
can be leaders in all WP UI development and so that the value of their
work can be multiplied when used by people extending WP. Lets face it:
Most people don't have the time/skill/enthusiasm for UI that leads to
beautiful useful easy-to-use tools. Making a beautiful table just a
function and a few paremeters away greatly increases the likelihood of
plugins having a good tabular interface.
I'm not sure I understand the backwards-compatibility problems except for
the obvious hump of initial pickup. All existing plugins that duplicate
admin functionality would continue to work with the current setup. Of
course as the admin changes those old plugins that don't use the proposed
API would slowly get uglier and less useful, but that would happen anyway.
If this API is available the authors will convert to the new system and
hopefully their problems will go away from there on. The net difference of
switching to a system like this is that '''some''' people will be able to
avoid UI rot while those who enjoy reverse-engineering HTML using Firebug
will still be able to do so. The only difference for the reverse-
engineers, whethey they do it cause they dont' know any better or because
they have special needs, will be that the tables/lists etc they copy will
be more consistent with each other than ever.
Also this example of switching from a table to a list seems like it might
be off-base. If the display of some particular kind of data by core
changed then it would just use the display function for the new display
type without affecting plugin uses of the old display function.
If you were showing a list of link categories as a table :
{{{
wp_admin_table($link_categories, $args);
}}}
Then you'd switch it to the list function instead (while also modifying
the $args to be whatever the list function requires to display the
link_categories to your satisfaction):
{{{
wp_admin_list($link_categories, $args);
}}}
It seems to me this wouldn't break any existing uses of wp_admin_table()
by plugins.
If a plugin is writing js/css targeted at core uses of these functions
(like the table that lists posts) then the current system is certainly no
better for them than the proposed API. Either way if the system changes
the css/js will need to be updated.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/11517#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list