[wp-trac] [WordPress Trac] #12935: Evolve the URL routing system

[WordPress Trac]

#12935: Evolve the URL routing system
--------------------------+-------------------------------------------------
 Reporter:  mikeschinkel  |       Owner:  ryan
     Type:  enhancement   |      Status:  new 
 Priority:  normal        |   Milestone:  3.1 
Component:  Permalinks    |     Version:  3.0 
 Severity:  normal        |    Keywords:      
--------------------------+-------------------------------------------------

Comment(by mikeschinkel):

 Replying to [comment:27 jacobsantos]:
 > I think after looking at this, I'm going to go another route that is
 simpler, in my opinion. This all appears complex, but I do think that it
 offers a better system than what is in place.

 That's fair, but then we are not starting from scratch. This approach
 would enable almost full flexibility with URL routing while changing as
 little as possible of what already exists in WordPress. While in a vacuum
 I would love to see a different system I think the most pragmatic approach
 is to honor the structure that already exists and only change what
 absolutely must be changed. I think there is a much greater chance of
 getting a workable solution integrated in core that take such an
 evolutionary vs. revolutionary approach.

 > How do you envision the system setting a callback and then calling it. I
 realize that most of what you are setting up is the routes part and not
 the full Controller implementation. I do think that specifying the
 callback as part of the Routes for when the correct one is found works
 more inline with the other controller implementations.

 Yes, you are only seeing the setup component so, respectfully, I don't
 think you can fully judge it yet, right? :-)

 I am aware of your advocacy of an MVC approach similar to Django and what
 I assume CakePHP, CodeIgnitor and Rails use but I think that would so
 significantly change that it is not viable, at least not in one
 revolutionary step.  The approach I'm taking it is maintain the concept
 for mapping URLs to query vars and letting query vars drive the loading of
 content.

 Yes, I agree that specifying the callback as part of the Routes might be
 preferable if we didn't have existing themes and plugins that expect the
 query system to work as is but I think this is the best approach
 considering where we are right now. Of course I'd love to hear from others
 on this issue like Andrew Nacin, scribu, hakre, Johnonolan etc. to see
 their opinion.

 BTW, I don't think there is anything that would keep us from extending
 what I'm doing to enable associating routes with callbacks at a later
 date, but I'd like to focus on working within the confines of the existing
 query system first.

 '''One point of note'''; the innovation over this approach compared to the
 existing rewrite system is that '''it inspects path segments instead of
 full paths'''. That has the potential to reduce the number of paths that
 need to be inspected for each page load as each path segment inspected
 further reduces the number of additional path segments to reduce, much
 like a b-tree database index speeds database access compared to sequential
 record access. Plus order of inspection for each segment becomes much is
 less important since there is less likely to be accidental matching and
 thus making plugins that hook paths more likely to be robust.

 Additionally inspecting path segments allows us to mix-and-match at each
 level, i.e. these paths could exist in performant harmony:

 {{{
 /about/  (post_type="page")
 /products/ (category="products")
 /about/team/ (list of post_type="person")
 /georgia/ (taxonomy of state, term="georgia")
 /my-new-car/ (post_type="post")
 /atlanta/ (post_type of "geo-region")
 }}}

 Inspecting path segments also allows us match via a variety of methods
 that could be optimized per specific use-case (via Memcached, for
 example):

  * Regex
  * Array keys or values, i.e. $segments[$segment] or
 in_array($segment,$segments)
  * Functions, i.e. MyMatchFunc($segment)
  * Expressions, i.e. i.e. (is_numeric($segment) and $segment >=1980 and
 $segment <=2099)
  * Database lookup count(new WP_Query("post_type=product&name=ipad"))
  * And so on...

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/12935#comment:28>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software