[wp-hackers] GSOC Proposal: Improved Controller

[Jacob Santos]

Computer Guru wrote:
> On 2/29/08, Jacob Santos <wordpress at santosj.name> wrote:
>   
>> *Abstract*
>>
>>  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.
>>
>>  *Solution*
>>
>>  * 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
>>  function/API.
>>
>>  * 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
>>  http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
>
> 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
> (sp?).
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   

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

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.

-- 

Jacob Santos

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.