[wp-trac] [WordPress Trac] #11517: Make Admin more MVC-like

[WordPress Trac]

#11517: Make Admin more MVC-like
----------------------------+-----------------------------------------------
 Reporter:  filosofo        |       Owner:  filosofo   
     Type:  defect (bug)    |      Status:  new        
 Priority:  normal          |   Milestone:  3.0        
Component:  Administration  |     Version:  3.0        
 Severity:  normal          |    Keywords:  admin-theme
----------------------------+-----------------------------------------------
 I brought this up in the October 15, 2009 #wordpress-dev IRC chat as a 3.0
 feature I'd like to see implemented.

 '''Current Problems'''

 Currently, most of the admin markup is hard-coded, with controller, model,
 and view all tangled up.  Functionality used in multiple places is
 replicated in each of those places.  And there's no API for plugins to
 generate admin-theme-specific markup, such as tables of data: for most
 cases plugins are forced to replicate markup based on observation.


 '''My General Proposal'''

 Instead, WordPress would be improved if:

  * Admin functionality were not unnecessarily duplicated.  This is a
 long-standing principle of software development known as "DRY" or "Don't
 repeat yourself."
  * Plugins could be agnostic about the particular markup of their admin
 pages.  By using an API for displaying their data or settings forms,
 plugins wouldn't have to make admin markup and style changes to match
 different WP admin environments.
  * Admin markup were more "themeable."  It would be helpful if plugins or
 themes were able to generate their own markup for common admin elements.

 This would involve a massive change in the WP admin pages, so I'm not sure
 what the best approach is to getting something like this implemented.
 Creating a patch would be a waste of time as it would grow stale almost
 immediately.

 '''How I think we should approach this'''

 My idea currently is to implement this as a plugin, a plugin that provides
 a parallel admin framework to the current admin system.  Then it would
 still be of use even without being committed to core and yet still
 demonstrate the main ideas.

 '''Concerns voiced during the IRC chat'''

 Here are some of the concerns that were raised in the dev IRC chat,
 followed by my responses:

 [[BR]]
 > making the admin area truely themable would add a TON of code

 Yes, there's no doubt about it.  However, in the end there would be
 ''less'' code to maintain, because less functionality would be duplicated.

 [[BR]]
 > we still need to be as light and fast as possible and avoid over
 engineering

 True.  I have a couple of thoughts about this:
  * First, the admin is currently very slow.  Not because of the PHP but
 because of all the CSS and JavaScript being loaded and processed.  A
 themeable admin would allow people to develop admin "themes" that, for
 example, don't use certain CPU-hogging JS libraries.
  * Second, the time difference between printing hard-coded markup in the
 admin and using an API instead is negligible.  And with a decent caching
 system, it's possible that the API route would be faster, because e.g.
 ''one'' function for printing tables would be stored in memory instead of
 a dozen different approaches.

 [[BR]]
 > Wouldn't abstracting the html creation make it a lot harder to change
 the UI in the future?

 No.  In fact the opposite is true.  For example, if someone wanted to
 change the markup of those tables displaying data, currently she would
 have to grep through the code looking for every place it's used.  With my
 approach, the markup would be changed in only one place.

 [[BR]]
 > [It] Would mean we have to stay back-compat with tons of stuff ... and
 what happens when the admin UI replaces that table with a list for
 example?

 This is a reasonable concern, because something like this could happen
 were the themeable admin done in the wrong way.

 For example:

 ''wrong approach:''

 {{{
 function print_table_of_data($data) {
 }}}

 ''better approach:''

 {{{
 function print_data($data) {
 }}}

 The problem with the "wrong" approach is that it provides a public API
 method for a particular markup result.  The second approach is a better
 name for a public API method because it allows those calling it to be
 agnostic about the particular markup that implements it.  So the concern
 I'm responding to here would be in play only if we don't decouple the
 markup from the public API.

 [[BR]]
 > well... think it would add a lot of back-compat work in most cases

 For core, there would be very little back-compat work, if any.  If---as
 the core currently does---you fail to have a public API, you don't have to
 worry about supporting that API in the future. :)

 For plugins that want to support older versions of WP, it would be as
 simple as checking for the existence of the API objects.

 [[BR]]
 > how hard is it to write few table rows when needed [?]

 If, for example, I want a table of data that is similar in markup and
 styling to the edit posts table, I have to apply class names like
 "alternate," "status-draft," "iedit", "check-column," "post-title,"
 "column-title," and I have to add attributes such as "valign" and child
 elements such as <span>, <strong>, and <div> in the right places.

 And there's no guarantee that any of it will be similar in the next major
 WP release; to work nicely across versions I have to figure out all the
 different approaches in past versions of WP.

 As a plugin author I would rather not have to parse any of that.

 [[BR]]
 > I think the problem will come when someone creates options, and WP_Forms
 drops them in a table, then the author includes a bit of JS, to make
 things fancy, which queues off the table.  If we switch to a list in the
 future their JS doesn't work.  As it is, if the admin section moves
 options to lists this authors plugin just still uses a table and still
 works

 If the plugin's JavaScript is tightly coupled to the markup, then the
 plugin author should probably not use a markup-agnostic way of generating
 that markup.

 So my questions for you, dear ticket readers:

  * What are the objections, if any, that you have to the idea?
  * Do you have any particular recommendations for implementing it?  For
 example, is there some sort of framework you've used to decouple data and
 presentation that you think would be a helpful model here?
  * Would anyone be interested in helping me write the code that implements
 this?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11517>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software