[wp-hackers] The problem with WP_Rewrite <<< RE: Options for Controller - Views

[Jacob Santos]

Well, I do want to thank you for taking the time to discuss this. Well, 
what I'm trying to accomplish is to use the content management and posts 
in WordPress, as well as the administration to manage a project that I 
hope to be extensible and maintainable. The problem is that I want or 
need to be able to have people who work on the code to be able to follow 
the entry points into different sections and templates without a whole 
lot of documentation and without a card house construction.

I will give it to you that I was trying to not use template_redirect and 
I may have been disgusted at WordPress when I realized that it was still 
required. I'm not trying to do what Martin is doing. What I'm trying to 
do is extend WordPress and add new pages and template files to achieve 
my goals. I have seen this done easily and extremely hackish, with page 
templates and I wish to avoid that monstrosity of code. Using a plugin 
instead, I can set up the URL paths that will load in specific template 
files and also prevent having to setup pages to perform the controller.

I will say that it is far easier to use the page template than it is to 
work with the WP_Rewrite and WP_Query. I'm looking to save time, but 
since I'm saving around two months by not working on the authentication, 
authorization, and administration, it will allow me to spend a small 
amount of time on the MVC.

I like MVC, it has proven to be the best way to manage a professional 
project that is maintainable, extensible, and gives freedom to focus on 
the other details of the project. Well, one of the advantages is that 
the controllers are located in one location, which I'll have to setup 
myself.

WordPress does follow some of the MVC (except that some of the model is 
mixed in with the views in some functions). While it isn't strictly MVC, 
it is closer to MVC than a strict presentation <-> business logic split. 
Hell, it uses a "Front Controller" Pattern in any case. I'm just looking 
to finish it up.

The second part is that if WordPress really wants to be used as a 
foundation and kick Joomla's ass, then it really needs to separate 
itself out from the controller part. WordPress (correctly in the 
majority of cases) assumes that you'll only ever use it for WordPress 
and when someone like me comes along and wants to use it instead of 
Joomla or Code Igniter, the decision is how hard is the learning curve?

I mean basically, I would like a system that allows for "routing" to a 
function or controller instead of having to do the workaround with 
setting a variable in WP_Query that I check in template_redirect. It is 
three steps when it should just be one.

I realize that the URL rewriting is separate from the Routing that is 
also separate from the controller. Basically, what you are interacting 
with is not the URL rewriting but the intermediary router which takes 
the URL rewrite and passes it along. Right now, the "router" part is 
contained in the WP_Query and template_redirect hook.

If you don't execute the process in the correct order at the correct 
hook stage then it all goes to hell. With a single function, it bypasses 
all of that. It also allows for rewriting when you want (as long as it 
is before or during the init stage).

Most likely the amount of additions I'm going to add to WordPress will 
most likely be larger than WordPress to where WordPress content 
functionality will exist of only a small part of the finished project. 
This said, The amount of work I am looking at and the amount of WP_Query 
and WP_Rewrite workarounds will make for extremely ugly code. I wish 
that it could be easier for someone to pick up on the code and 
understand what the code is doing, but I still believe it would be 
difficult except for those who understand a vast amount of WordPress. I 
am hoping that anyone can extend my project in the future, including 
adding new controllers as simply without having to figure it out on 
their own from my code.

With the community behind WordPress, the MVC implementation, no matter 
how rigid it may or may not be in the beginning, will most likely be 
expanded to encompass far more flexibility than any framework or class 
library. Or at least if it is done correctly. Definitely going to call 
for unit testing. It will be better than what is currently there.


More below:

Otto wrote:
> On Fri, Nov 27, 2009 at 8:13 AM, Jacob Santos <wordpress at santosj.name> 
> wrote:
>  
>> 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.
>>     
>
> In that sense, WordPress has no controller, as you understand it. It
> doesn't really fit the MVC mold. Note: I think that's a good thing.
>   

Actually, it is that WordPress does follow MVC in some regards that it 
works as well as it does currently. Everything is separated in a sort of 
model, which you could just call the WordPress library with the 
templates serving as the views. Most people when working with just 
WordPress theming, don't have to worry about the controller aspect, 
since there is no need.

It is only when you wish to use WordPress for something that it was not 
meant for, that you need to start questioning whether using WordPress at 
all is a good idea. I'm talking about a 3 or 4 month project that will 
dwarf WordPress in functionality, but I'll rather be spending the one or 
two months working on the code quality of the actual project and not 
recreating what WordPress already has, if at all possible. That is time 
I could either have the project done sooner or used to improve the 
quality of the code and add additional features.

>> 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.
>>     
>
> Fair enough, but I don't see any benefit to doing this. What will you
> be better able to do with a template-redirect.php changed into some
> class system that you cannot do right now?
>
> Also, again, I must state that this subsystem (file) has zero to do
> with URLs, parsing, rewriting, the query... So how do those fit into
> your idea?
>   

Well, besides the cutting of the three or four part system down to one 
and converting that file to functions or classes, there is none. That 
file has always bothered me, so I wish to finally get to a project I had 
my sights on for the past 14 to 16 months.

>> 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 just don't want you to waste your time and then to become
> disillusioned if others dislike it. I'd prefer to understand what it
> is that you want to do before you go and do it. I'd like to help make
> improvements to the existing code, if you can tell me where you think
> there are failings.
>   

What I'm saying, is that I'm going to do it whether or not it is going 
to be accepted into WordPress. Simply, I would just release the project 
source as a fork, much like WordPress Mu is now. At some point in the 
future when the rewrite has been tested, is stable, then great. However, 
I think what BackPress is trying to solve would work well with a generic 
Controller implementation that doesn't suck.

>> 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 understand this, but I found it difficult and confusing in every
> rigid-MVC style system I've tried, which is why I pretty much hate MVC
> in general. It's rigid and inflexible in 99% of the implementations of
> it. It's a bad way to write web-code. IMO, of course.
>   

Yeah, I will agree that when you have a small project, MVC probably 
would be more than it is worth. However in my instance, if I tried to do 
it any other way, I'll be in for a nightmare trying to maintain the 
code. I already found that out with a small project. After doing the 
presentation <-> business logic path and extending to MVC, I can see the 
vast advantages a true MVC implementation inherently gives.

Jacob Santos