[wp-trac] [WordPress Trac] #11517: Make Admin more MVC-like
WordPress Trac
wp-trac at lists.automattic.com
Sat Dec 19 21:09:20 UTC 2009
#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
More information about the wp-trac
mailing list