Route using database information

[eluser]Aken[/eluser]
Got it I was confused how that would help his situation, then I read a little more carefully and realized he wasn't trying to pull dynamic information like I am, but pull physically-coded controllers, pages, etc.

[eluser]wiredesignz[/eluser]
[quote author="WanWizard" date="1226037357"]This is indeed what I mean with writing my own front controller. But it seams that instantiating a second Controller class within the first doesn't work, to that route is blocked at the moment.[/quote]

Modular Extensions HMVC may be of some help here. (check the link in my signature)

Welcome to the forums.

[eluser]Frank Berger[/eluser]
I've built a little tool, hooking into the config-files with the hook-framework, which enables one to overwrite or extend any config-file setting from a database, with additional support for virtual host handling, user/client handling and accessing ip handling (means you can store/overwrite/extend diffrent config-options for diffrent domains and such), and it works with any file in config/*.php and without extending/modifying existing controllers/models/libraries/core-system. (with the exception of the hooks.php file itself).

If there is an interest for this, I'd publish it..

cheers
Frank

[eluser]James Gifford[/eluser]
@Frank Berger: I am interested in your solution for updating config settings from a database.

I need to set dynamic routing based on the user's settings stored in a database. I'd like to make the solution invisible to the user but so far the best I can do requires the user to change file permissions for the routes.php file. Still, if that's the best that can be done its not so bad.

[eluser]HdotNET[/eluser]
The keep it simple version... no caching at all but could be easily integrated.

table

Code:

CREATE TABLE IF NOT EXISTS `routes` (
  `id` int(11) NOT NULL auto_increment,
  `route` varchar(255) collate utf8_unicode_ci NOT NULL,
  `controller` varchar(255) collate utf8_unicode_ci NOT NULL,
  PRIMARY KEY  (`id`)
);

config/config.php

Code:

$config['enable_hooks'] = TRUE;

config/hooks.php

Code:

$hook['pre_system'] = array(
                                'class'    => 'RouterHook',
                                'function' => 'GetRoutes',
                                'filename' => 'RouterHook.php',
                                'filepath' => 'hooks'
                                );

hooks/RouterHook.php

Code:

class RouterHook{
    function GetRoutes(){
        global $DB_ROUTES;
        $db_conn = mysql_connect('hostname','username','password');
        mysql_select_db('database',$db_conn);
        $sql = "SELECT * FROM routes";
        $query = mysql_query($sql,$db_conn);
        $routes = array();
        while ($route = mysql_fetch_array($query, MYSQL_ASSOC)) {
            $routes[$route['route']] = $route['controller'];
        }
        mysql_free_result($query);
        mysql_close($db_conn);
        $DB_ROUTES = $routes;    
    }
}

at the end of config/routes.php

Code:

global $DB_ROUTES;
$route = array_merge($route,$DB_ROUTES);

[eluser]Tom Schlick[/eluser]
i really do love how 95% of the challenges i come across while building my cms have already been worked out already by awesome codeigniter people. i truly love this framework and the community behind it. TAKE THAT CAKE!!!

[eluser]Unknown[/eluser]
This is probably bad practice, but what about routing all requests to 1 controller that figures out whether the uri corresponds to a database record? If not, generate a 404.

[eluser]xwero[/eluser]
Naldu it's not a bad practice but you better keep the redirection to a minimum.

There is one thing i would change in HdotNET's code and that is adding caching because the database should only be queried for the routes if there are changes.

[eluser]n0xie[/eluser]
[quote author="naldu" date="1242221594"]This is probably bad practice, but what about routing all requests to 1 controller that figures out whether the uri corresponds to a database record? If not, generate a 404.[/quote]
That's basically how our CMS works.

It 'hooks' into the standard CI and matches the url against a lookup table. Actually it matches against the cache, then matches against a lookup table.

The reasoning is simple: write once, read many. The big performance gain is that the hook initializes before any of the Database Class is loaded, which means it doesn't have to wait to establish a database connection. This way, if the page was already rendered, it reads directly from cache, just as a static html page would, which means a significant increase in speed.

If it doesn't match against the cache but matches against the lookup table, it loads a standard controller and passes the lookupId to it. where the CMS builds the page (loading models/plugins/template based on the lookupId) , writes it to cache, then outputs to the browser.

This will take care of about 70-90% of your 'standard' website where the only thing that changes is content.

This behaviour can be overwritten by adding a controller name to the lookup table in which case it loads that controller instead: this is to be avoided since it will result in 'obscure' routing and should be only done in case you have to hack the system. The preferred method works like this:

If the url does not match against either the cache or the lookup table, it processes the url as 'normal' trying to match it against a controller. This way when building a CMS you can build a 'contact' controller without having to code all sorts of exceptions. You would write it just the way you would any normal CI controller complete with form validation and some javascript 'bling'.

The pros of the system are:
- good caching speed, therefore ideal for heavy traffic CMS'es
- It 'hooks' into the core classes therefore it doesn't 'meddle' with anything CI specific. You can upgrade to newer versions without problems.
- Since it 'hooks' into the core classes, no special namespaces or conventions exist.
- You can rewrite or use any url you want. Customers can build their own url's as long as they are valid url's (this you should of course check in a backend).
- Since we have a table that has a one to many relationship to 'models', you can add 'plugins' later.

[eluser]WanWizard[/eluser]
Just a quick update.

I finally fixed this by routing all page requests to a single bootstrap controller. This controller would analyse the request, and then load other controller(s) to process the request.

To do this I've written a new method for the loader class that allows controllers to load other controllers.

So, quite similar to some of the other solutions presented here.