[wp-hackers] GSOC Proposal: Improved Controller

[Computer Guru]

On 3/2/08, Jacob Santos <wordpress at santosj.name> wrote:
> 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.


Thanks for the explanation, Jacob.
You're right, of course - I can see the overhead being very negligible
if it's properly done.