[wp-hackers] Controller Implementation

[Jacob Santos]

On 7/2/2010 6:43 PM, Mike Schinkel wrote:
> 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?
>    

WordPress isn't so much a controller as it is a blogging system and 
content management. If you replaced the controller with Zend Framework 
Controller, TinyMVC, etc, it would still be WordPress, just with a 
different implementation for the front controller. As for the plugins, 
it might be difficult to provide a similar system for them to work with. 
Not the best idea, but a custom solution would be tailored to 
WordPress's history and its current implementation. However, given that 
whenever you rewrite or replace something, you inevitably leave out 
certain cases that plugins use, it might be impossible to replace it 
completely at the beginning.

I'm actually not talking about replacing it, only complimenting it at 
this point, until at which time enough plugin / theme developers use the 
new system and it can be deprecated and the rest of the system designed 
to use the new one. However, given how simple my system is, I don't 
really think replacing the WordPress controller is required. Both 
systems can work together and even your implementation can be used in 
conjunction with my controller implementation.

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

I think that is one of the reasons for the complexity in WordPress. If 
the MVC was implemented correctly, from the beginning, then I believe it 
would be far different and easier than what it is now. MVC isn't about 
mapping URL to a query, it is about mapping the URL to a controller 
which handles the data. In this, you have a complex system that combines 
the Model with the Controller and simply loads the view, in a sort of 
business logic and presentation separation with front controller thrown 
in. I think that by separating it back out to using a controller for the 
different contexts, it will be faster and easier to understand. It 
should also be easier to extend and debug since anyone can look at it 
and not run with their tail in-between their legs or simply shake their 
heads thinking "WTF?"

> 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 think this is what we need to get away from. The controller doesn't 
bypass the query, it calls the query and then passes it off to the view. 
In this, the controller will own some of the responsibilities of the 
WP_Query in setting up the environment for the view and The Loop. 
However, this gets away from the short terms goals. It would require a 
mass amount of debate, testing, wrangling, strangling, and time to 
replace WP_Query, WP, and WP_Rewrite with a new system that both 
compatible and works. Well, it could be done in the two months, but I 
don't believe the powers that be will allow for such mass changes to the 
core. Furthermore, once the change has been implemented, it better be 
the best system ever, because it is unlikely to change for a long, long 
time. That and given that any new system is going to have its quirks, 
bugs, missing documentation, etc, it will be a few versions before it is 
really tested and ready for prime time.

The gain is a system where the MVC works as Zend Framework, CodeIgniter, 
etc work. It is unlikely that those programmers will pick up WordPress 
and develop and app with it, but it does allow for them to take on 
clients that decide to use WordPress and need to convert the code from 
those frameworks to WordPress. If the systems are similar, then all that 
should be required is creating new controllers and views for WordPress. 
It won't be a one to one, it never is for any framework system, but the 
learning curve will be much lower for those who are already used to 
those systems. Also, it goes a long way to allow for WordPress 
developers to pick up MVC frameworks in the event WordPress is not the 
best solution. I could name a few plugins that should never have been 
created using WordPress as the foundation or at least not in the way 
they made it.

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

It already works inside of WordPress, it just lacks the dispatcher. I 
mean, I could try adding the dispatcher in WordPress, but since it is DB 
based, it might be a bit difficult since plugin developers like to use 
array(&$this, 'method') and that won't work. It would require a new 
array structure. I'll see about adding it to the implementation and then 
people will be able to test it. However, I'm moving forward with my 
existing codebase with a few modifications based on the discussion here.

Really, what I want is the best solution and I don't believe I alone 
will come up with it. There exists many MVC libraries and frameworks, 
but majority of the existing ones are PHP5+ only and WordPress is still 
PHP4 compatible. If it is done right, then a plugin should be able to 
use the Zend Framework based on what exists currently in WordPress. The 
goal should be to ease the transition to either an existing PHP5 
Controller implementation in the future or a simple Controller in 
WordPress that eases some of the pain with working with it.

I don't think documentation will help because it still works differently 
than all the other Controller implementations and still has plenty of 
"WTF?". My goal is to hopefully ease that and I will have more to show 
come this weekend.

Jacob Santos