One Scaffolding to rule them all

[eluser]Michael Ekoka[/eluser]
Since the aim of Scaffolding is to quickly access tables in the db, I find it simpler to have one controller solely used for that purpose.
I use something like this:

Code:

class Scaffold_controller extends Controller{
    public function __construct(){
        session_start();
        parent::Controller();
        if($this->uri->segment(4)=='switch'){
            $_SESSION[APPPATH]['table_to_scaffold']= $this->uri->segment(3);
        }
        $this->load->scaffolding(@$_SESSION[APPPATH]['table_to_scaffold']);
    }
}

Then to scaffold a table, in my url I can simply enter the name of the table and authorize the switch:
http://localhost/myapp/scaffold_controll...ble/switch

in reality it would look more like this :
http://localhost/blog/scaffold/go/entries/switch

As have been said by wiser men than me, use scaffold with lots of caution and in dev only.

[eluser]Unknown[/eluser]
You could have that less redundant if you just check $this->uri->segment(x) (forgot, which one it was) against the scaffold trigger ...

[eluser]Michael Ekoka[/eluser]

You could have that less redundant if you just check $this->uri->segment(x) (forgot, which one it was) against the scaffold trigger

I'm not sure what you mean, but i'll try to explain the logic behind what i did, if you have a workaround for the problem that i encountered please share:

the original structure of the scaffolding link, i.e. the way CI currently expects it to be submitted is:

controller/scaffold_trigger

Then, from the controller one would load the scaffolding, select the table to scaffold, etc. The problem is that you have to revert to the controller each time you need to switch tables, since the url does not include which table is involved. Everything is expected to be found in the controller's constructor. So to add that capability from the url, I decided to add the third argument to the link, making it:

controller/scaffold_trigger/db_table

The value would then easily be retrieved from the $this->uri->segment(3). Unfortunately the urls automatically generated in the scaffolding views by the core mechanism (edit, add, delete) also ignore which table is involved and only know 3 things:

controller/scaffold_trigger/action_to_perform

I really wanted to keep the code unobtrusive and rather than modifying the core scaffolding library to include the db table name in the urls generated for the views, I chose to store that value in a session, hence:

Code:

($_SESSION[APPPATH]['table_to_scaffold']= $this->uri->segment(3);)

Only one problem, during scaffolding actions, the third argument in the url (action_to_perform) could overwrite my table name. To avoid this, I need to put a flag that authorizes the rewriting, hence:

Code:

if($this->uri->segment(4)=='switch'){
    $_SESSION[APPPATH]['table_to_scaffold']= $this->uri->segment(3);
}

and that flag is included in the url as :

controller/scaffold_trigger/db_table/switch_authorization_flag

So if your database has a table called "edit" you can select the table with
controller/scaffold/trigger/edit/switch
and edit a record in that table with:
controller/scaffold/trigger/edit/record_id

I could probably include a list of reserved action names in an array and exclude them from possible table names, but who knows the next time someone might need to call a table "edit".