[wp-hackers] Controller Implementation
wordpress at santosj.name
Sat Jul 3 01:03:06 UTC 2010
Mike's ticket deals with extending the routing system in mapping
WP_Query to URLs, whereas I'm dealing more with the whole of a
controller implementation. So from what I can gather, and correct me if
I'm wrong, it would be rewriting or extending what WP_Rewrite handles
and extending what WP_Query does. The segment idea, and you'll have to
read the ticket for more, is a great one. I haven't yet seen Mike's
solution and I would like to, but I don't want to wait that long for a
Definition of some terms:
Router / Routing : Much like a network router, you are mapping a URL
path to a controller (in my case) or in Mike's case, it would work much
like what it does now, just have more options. If you understand the
WP_Rewrite system now, then Mike's proposal is just taking that and
adding more features to it.
Dispatcher: This is really what is missing in WordPress. You can setup
the routes in WordPress, but once the route has been matched, then it
just writes to a variable and requires that you check it in an action,
either template_redirect or sooner (better if it is done sooner to
prevent wp() from running and setting 404 calls, if you didn't use
WP_Rewrite to set it up). It won't automatically call your function or
class. This is part of my proposal to the rewrite. All MVC frameworks
and libraries will dispatch to the controller once the route has been
Controller: Really, the controller handles setting up the view, using
models to connect the data to the view. Whereas, in most controllers you
would only set up the data that you need, WordPress tends to setup
everything needed for the loop, whether it is needed or not.
There are more "features" and implementations may get into actions,
modules, and other concepts to ease the pain of setting up the
controller, but for WordPress it isn't important because I believe the
Plugin API handles much of what the others implement as part of the
My focus is getting away from the database option where reasonable. Some
routes are static and therefore do not need to be placed in the
rewrite_rules option. Some routes do not require everything that the
Loop requires and the permalink will not change. The difficulty and I
understand truly, is that posts, pages, archives, categories, and tags
can be customized and this behavior does not have to change. Neither
proposal is suggesting making the permalink hard coded. Some routes are
hard coded regardless and therefore do not need to be in the database.
The reason it is useful for the dispatching is that you don't require
many functions to hook into an action to test whether they need to run.
Any function or class that is called knows full well that it is meant to
run and only needs to focus on setting up the data for the view. Really,
as I was thinking about it, it might be better to require all
controllers be classes, since the init process can setup data for the
class. I just like the idea that WordPress allows for functions and
classes for majority of features, so there is hardly any reason to block
that for this one.
On 7/2/2010 6:43 PM, Brian Layman wrote:
> that when a request arrives at the site, isolating a single post may not be
I don't see how, part of the router implementation is to allow for this.
However, honestly, the posts and other dynamic permalink structures are
not meant for the router anyway. I implemented what it might look like
based on existing WordPress code, but I've since decided to leave
WordPress as it is and simply implement a separate system that functions
separate and before the WordPress front controller. Most plugins know
what their permalink is going to be and therefore do not require such
dynamic tests and generations.
It has given me an idea, in that difficult plugins might wish to set a
base for their permalink. So say, if you had two gallery plugins using
the system, the plugin would allow you to set the base. For example,
gallery plugin 1 would be '/gallery/' and gallery 2 plugin would be
'/friends/'. So instead of conflicting plugins causing issues with one
or the other able to be activated at a time, both could be.
> and 2. when permalinks are determined as a "post" is created, a
> unique permalink can no-longer be guaranteed.
Well, normally when working with a MVC system, when you change
"permalinks" as it is, it is manual process, so you would simply keep
the old controller and then redirect to the new. Kind of like the
canonical URLs, but manual.
The Dispatching process does not work that way. The router simply checks
the URL and once it matches one, it stops and then dispatches to the
Controller. Router -> Dispatcher -> Controller. There is no
reverification process. The controller would simply go through the URI
segments and find the post and then load the view. I think I will also
create a route that works with the permalinks in order to have a better
example of how this will work.
Alas, that is also why I think this is good. WordPress doesn't actually
use its own system to create the routes, in so much as to give an
example to plugin and theme developers as to how to use the system. The
new controller implementation will have many examples of how it is used
More information about the wp-hackers