[wp-hackers] Controller Implementation

[Mike Schinkel]

Hi Jacob,

I definitely agree that routing in WordPress is complicated unless are really familiar with how it works.  And I agree that WordPress does not use a "true" controller and that controllers provide a nice architecture.  OTOH, after getting to intimately know how WordPress routes URLs (although at times I still struggle with putting that knowledge to use given its complexities) I wonder if swapping out the existing routing and replacing it with a "true" controller wouldn't change WordPress so fundamentally that is would in effect no longer be WordPress?  

What I mean by that is WordPress is designed around the query where a URL(-like) query maps to a SQL query and WordPress sets lots of context flags based on the query.  If we had a controller that bypassed the query then much of the core code and many of the plugins written for WordPress would be written on obsolete concepts and without a solid replacement for inspecting context.  IOW, using a controller would require us to add a new "context" system (and/or use the old one by complex mapping, but then what have you gained?)

I'm not disagreeing with you (yet?) but I am unsure how a URL controller could ever work within WordPress given all the existing plugins and the existing pool of knowledge and experience that people have regarding the way WordPress work today?  I guess I bring this up to further spark discussion/debate on the topic.

-Mike
P.S. For background for those who've not been paying attention to ticket #12935 I basically proposed a replacement for the WP_Rewrite system I called WP_Routes that would replace as little as possible in core WordPress. WP_Routes would inspect URL paths segments by various matching methods rather than by regex match of the full URL currently used by WP_Rewrite.



On Jul 2, 2010, at 5:37 PM, Jacob Santos wrote:

> I think the problems can be listed as the following:
> 
> 1. Too difficult without a lot of documentation.
> 2. Isn't extensible enough to automate some queries for posts.
> 3. Not a true controller implementation.
> 
> I think Mike's ticket (#12935), deals with the second. Mine deals with the
> third and neither really deal with the first at this time.
> 
> I think the biggest problem with the routing is that it isn't dispatching to
> any controller. Therefore, you can set the routing to get past the initial
> 404 settings in WordPress, but you'd need to handle the dispatching
> yourself. It is easier, to just do the dispatching yourself and then
> "correct" the 404 status and the title or hook an action that starts before
> wp() function executes.
> 
> The goal of the router should be to only find the controller for dispatching
> to. The querying that is part of the WP_Rewrite and WP_Query now complicates
> and confuses the role of the router and doesn't satisfy the separation of
> roles. Which is why rewriting the entire process would be better, but
> generally off the table as backwards compatibility is required. It is also
> isn't necessary to rewrite everything to implement the new controller
> implementation.
> 
> I propose the following:
> 
> For WordPress 3.1, include the completed controller router and dispatcher,
> separate from the current WordPress front controller. Including a new action
> that takes place before wp() function executes.
> 
> Some time after that, move some of the rewrites option to the new controller
> and start dispatching to functions and classes for feeds and other
> non-essential actions that can be tested and if there is any problem can
> wait for a minor release or next release. Meaning less people will notice
> after they upgrade and some edge cases weren't completely tested. During the
> period between 3.1 and say for example 3.2 or 3.3, enough plugin developers
> should be using the new controller as to allow for enough testing to certify
> that it is stable enough to use in core.
> 
> After that, address the second in the above list while moving the rest of
> the post, pages, etc to the controller. Deprecate the old way and move the
> WP_Rewrite to the new system where logical.
> 
> Any suggestions on the implementation, current (in patch) or future, and
> ideas?
> 
> Jacob Santos
> 
> #12935 - http://core.trac.wordpress.org/ticket/12935
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers