[wp-hackers] GSOC Proposal: Improved Controller
wordpress at santosj.name
Sun Mar 2 20:30:40 GMT 2008
Computer Guru wrote:
> On 2/29/08, Jacob Santos <wordpress at santosj.name> wrote:
>> Improving the current controller/query model to allow for simple hooking
>> for adding pages and queries. This will allow for even the most novice of
>> users to create pages not dependent of query vars and having the user
>> create pages with some tag. It will also allow better CMS capabilities.
>> * Single function for setting the permalink (also query path) and the
>> query. Then passing the function and/or page which will be redirected to.
>> * Improved API for adding query conditions (functions are easily added by
>> plugins, but need better way to hook into conditionals) with single
>> * Will not change the concept of "Views" (see Template Work Flow).
Actually, I guess it will change the concept of the WordPress View
(Template Loader) to be more dynamic.
>> * Create new library or improve current library for better testability
>> (current code might already have test cases).
>> * Arguments Against *
>> The current method works well and wouldn't need that much work to add the
>> above without to much refactoring. With improved documentation from
>> examples of the community, developers will know the ins and outs of the
>> Controller model.
>> Jacob Santos
>> http://www.santosj.name - Personal Blog
>> http://funcdoc.wordpress.com - WordPress Function Documentation Blog
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> Jacob, would this conform to a more MVC-style approach at content handling?
> Also, a quick question: what about the overhead? (way I envision the
> implementation is a checking incoming requests against an array of
> stack<filters> and if it matches send it to the appropriate handler)
> Every single request now has the burden of checking the correct
> destination through a number of complicated steps (preg_match, etc.) -
> even though most requests will probably pass through un-accosted
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
As for the overhead, while thinking about it some more, WordPress
already does the View and Model parts, which are no problem. Correct me
if I'm wrong, but the Controller acts as the gatekeeper for which View
is loaded. If you break it down, the Model is the WordPress API
contained in wp-includes/. The View part is contained in the theme folder.
If you go off the Zend Framework (which has always confused me on where
exactly the View takes over), the View is contained within the
Controller method. The Rewrite component finds the Controller, which
executes the View, which loads the Template. If you apply this to
WordPress, the WP_Query is the Rewrite and (Front) Controller, which
passes to the Template Loader (the View), which loads the Template. That
is my interpretation, do correct me if I'm wrong.
The improvement will separate the Rewrite component and Controller
component from the WP Query and improve the Template Loader (View) to be
an API instead of a logical block specific to WordPress. Also, it might
be possible to remove the Template Loader file and be contained in the
Controller function/method which will automatically load the correct
files, if the file exists( else load index.php).
There will have to be test cases to tell if the improvements will add
additional overhead from the current implementation. However, I think
convenience should trump optimization at any point, but it should be
optimized as much as possible, while still retaining the feature set
requirements. You are right about the steps, but usually you place the
most often used rule at the top (homepage, then single post, then single
page, etc), with the worse cases and not often used cases at the bottom,
with a final case to capture everything that isn't captured by the above
rules (404 in WP case?). Once you find the rule that matches, you stop
and run the controller portion.
The second feature set, will be to allow for the Controller component to
be completely replaced, using a system like how the object caching
replacement works, with something else, including the old system. So I
think this feature set will have to be one of the first features
implemented. However, I remember reading that the current Controller can
already be replaced and there is already a solution which does replace
the Controller with Zend Framework. I'm unsure how that works, since I
haven't used it.
Note that the WordPress does in fact implement a simple Rewrite
component separate from the WP Query component, however that also
includes the mod_rewrite writing, so what is in the mod_rewrite Writer
Component will be separated and refactored in to a improved Rewrite
model supporting the above. While the mod_rewrite Writer will be its own
component separate from the Rewrite Component.
So with the final improvement the work flow will look a lot like this:
URL is checked to see if it uses query vars or query string or
mod_rewrite method -> URL is matched against one of the Rewrite rules ->
Matched rule loads Controller -> Controller runs View logic loading the
At the very least, it should remove the argument that WordPress doesn't
do MVC or at least provide a better debate against that argument,
instead of it, "Kind of follows it, which means it does MVC." Also,
while hacking WordPress, there have been times when I wanted to
completely overwrite how the controller system works and this API, would
allow that to happen without cutting the core to pieces and increasing
the work load of upgrading.
Thanks for replying to the proposal.
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers