Re: Microformats and logical URLs -- mod_rewrite

[Victor Engmark]

On 5/5/07, Klaus Weiss <address@hidden> wrote:

> I propose support the new URI design (see attached file) only at the new
> Klaus' architecture, but not at the current one.
>
> The new architecture must support that URI design without the need of
> modrewrite. Realizing it directly with PHP will speed up the webapp.  Klaus,
> should we do it at the Controller?.
>
> So, I am going to cancell the that ?6819 task.
>
> What do you think?

I wonder if it isn't better to move the redirection stuff to PHP
litself? Currently there is a dispatcher file which do this stuff and it
would be easy to add some special rules for backward compatibility.

Here is some code of an example controller which tries to solve the
above issue:

<?php
class Offers extends Controller
{
        public $name = 'Offers';

        public function view()
        {
                if(!$this->data['GET']['id'])
                        $this->redirect('/offers/viewList/');

                /* Show specific job entry. */
                ...
        }

        public function viewList()
        {
                /* Show all job entries. */
        }
}
?>

The requested URL should looks like '/offers/view/3' if mod_rewrite is
used. In the config file there is this option:

define('SITE_MOD_REWRITE', true);

which indicates whether mod_rewrite is enabled You can disable it easily
by setting this constant to false. This change will be detected and all
URL's which are described with the HTML helper method `link` will be
changed so everything run without the need of mod_rewrite.

There is some lowlevel code which extracts now the necessery information
from the URL. Currently this code understands the following layout:

/index.php/ControllerName/ActionName/Param1/Param2/...

However it can be easily changed. I think this is an interesting feature
due to its flexibility.

I'd like to add something I just realized about this syntax: It's fundamentally inflexible, because when (not if) you remove or change a parameter, you don't know how to treat old URLs, which will come from bookmarks and search engines. You could circumvent this by having the parameter name as part of the value string (
e.g., "/p1%20value/"), but then you're pretty much back to the old solution, but with a non-standard syntax.

Another thing is that optional parameters will lead to some strange syntax, since you'll have either URLs ending like "////value4/" (as noted by others) or "/null/null/null/value4", or you'll have to require every parameter up to the last one which is not null to be included, to make sure that the positions are correct - 
I.e., to submit only the third parameter, you'll have to include the two before, e.g., "/null/null/value3/" == "/null/null/value3/null/", but "/value3/" won't send the value to the right parameter.

Also, this won't work unless you force a rewrite for every single form request on the server. I don't know how much traffic this site will get, but I really doubt the gain of this is worth such a non-standard single point of failure.

As far as I can see, this kind of URL is only usable when there's an unambiguous hierarchical structure to the contents, not for forms. Also, AFAIK it's not used by any of the big sites out there, probably for similar reasons.

Comments / corrections?

-- 
Victor Engmark