[wp-hackers] The problem with WP_Rewrite <<< RE: Options for Controller - Views
wordpress at santosj.name
Fri Nov 27 14:13:23 UTC 2009
Yeah, I'm talking about the controller as a whole, which usually
includes the URI parsing, the Router, and the classes or in WordPress's
case, functions. I'm also talking about the views, because the
controller that is called loads the specific view. Actually, to clear up
any confusion, the WordPress views, i.e. the templates and their files,
will not change. The only thing that will change is that there will be
functions or classes that loads the view, instead of a if...elseif block.
Also, it isn't as if I could remove template_redirect completely. Any
system would have to be backwards compatible with what exists now, as
well as existed years ago. Well, at least if I wanted the patch to ever
be acceptable, besides the whole issue of breakage and its experimental
nature. I remember doing that one time, thinking, "Well, it should just
work right if I follow the standard and documentation." Yeah, I learned
something from that experience, but with the controller implementation,
I'm not relying on whether or not someone else thought of all of the
bugs. If there are any bugs or SNAFUs, then it would be all me. I
couldn't care if it is going to be acceptable for WordPress, I'm doing
it for me and if anyone wants to see it in WordPress, then so be it.
I'm not asking if WordPress merits a rewrite (more likely a refactor
into the new system) of the WP_Rewrite and WP_Query. I'm asking if in
anyone opinion if I should extend the current or replace it. I think of
the people who have voted, the consensus is that it should be replaced,
which is what I'm going to attempt to do.
Also, the whole thing about the parameters. That is already possible
with many controller implementations. Only the most rigid don't allow
you to do that with the URL string. However, one thing, if you wanted
/tag/whatever to set $tag = whatever, then do the same thing as setting
certain parts to parameters for a controller. So you would still send it
to a controller, it just wouldn't be the "tag" controller class or
function. Or I mean, it could be the tag controller to save time and
automatically call the tag controller class which sets the $tag
parameter to "whatever".
I mean, let me wrote the code and put it up as a patch. You did give me
more to think about, but I just don't think you are going to convince me
that WordPress way of doing things is all that intuitive and clean. If
it was intuitive, then I should have been able to get started a lot
quicker. Really, I would have to change my whole way of doing things
from having first started with other frameworks that implement the MVC
the way it should be to allow for others to work of it.
I'll probably have some code in 4 to 6 weeks, unless life takes me for a
ride, then probably never, so I'll rather not completely waste your
time. It might make a good blog post for the next person who succeeds
me, if I fail. That way you don't have the whole, "Are we really have
this conversation again?" If we aren't already. I might have brought it
up ages ago, just not this specific question.
> On Tue, Nov 24, 2009 at 6:56 PM, Jacob Santos <wordpress at santosj.name> wrote:
>> My main problem with wanting to rewrite it and I apologize for going off on
>> a tangent, is that I shouldn't have to think and test as much as I do when
>> working with WP_Rewrite. I shouldn't have to do all sorts of calls to
>> functions to set up a rewrite when all I need to do is use one hook. Why do
>> I have to use the long way, when I can just use the shortcut named
>> My point is why even have all of that code when you have to use
>> template_redirect anyway.
> Umm... because template_redirect and WP_Rewrite don't do the same
> things in any way, shape, or form?
> - You use template_redirect to change the final output of the
> WordPress system, to basically create a custom "view".
> - You use WP_Rewrite to parse the URL into query_variables.
> These aren't even close to similar. They have absolutely zero to do
> with each other. Why in the world would you want to combine them in
> any real way?
>> You are telling me and actually believe that it is an excellent idea, which
>> I can't understand, that I can either spend hours going through and using
>> WP_Rewrite just to have to use template_redirect. You are basically telling
>> me that my only advantage is that I won't get the 404 title when WP_Query
>> parses the query vars and determines that the page doesn't exist.
> No, I'm telling you that you're completely confusing these two
> entirely separate and different subsystems, and I really don't
> understand why.
> Also, hours? It's like 5 lines of code to add a new rewrite rule. I
> would think that the "add_rewrite_rule" function is relatively
> straightforward. The add_tag stuff is even easier, if you want to
> stick close to the existing structures.
> Okay, the flush rules stuff could be done better, I grant you. This is
> a speed optimization that needs to be worked on.
>> I think the high learning curve is driving many people away. It doesn't work
>> like you would assume it will work and requires a lot of extra work that has
>> to be done exactly right in order to work correctly.
> Okay, I'm no super-genius, but I understood exactly what it was doing
> in about 30 minutes. It works exactly the way I expect it to work.
> I am totally and completely confused with your concept of somehow
> integrating the rewrite parsing system into the controller and router.
> That makes little sense to me. It confused me with the Zend MVC system
> as well, because (and this is key) I don't want URLs to immediately
> direct to a specific view, I want URLs to determine dynamic
> URLs are not Views. If I have a URL like /tag/whatever then I might
> want to set $tag=whatever, not to direct to the "tag" view with
> "whatever" as a parameter. Because what if I want to combine
> parameters? How would your concept handle /category/X/tag/Y ?
>> I think that it is incomplete, everything right now was written not to allow
>> for extension, but to allow for WordPress to kind of have a sort of front
>> controller implementation.
> On the contrary, I find the WordPress system to be far more flexible,
> easier to understand, and easier to use.
> I would absolutely not support your system without a better
> explanation of exactly what the hell you're talking about. Because
> what you're describing, as I see it, is a massive step backwards.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers