[wp-hackers] Controller Implementation
wordpress at santosj.name
Sat Jul 3 01:33:26 UTC 2010
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.
More information about the wp-hackers