[wp-hackers] Controller Implementation

[Jacob Santos]

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 
solution.

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 
matched.

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 
controller.

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
> possible

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 
and setup.