[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