also make sure to XSS clean the table names if you are planning on passing them in from the URL. Eric On Fri, Nov 30, 2012 at 2:07 PM, Tom Haws wrote: > In other words, wouldn't you have the model functions build the data > arrays the way the views are going to need them, then call that output from > the controllers and send it to the views? > > -- > "To forgive is the highest, most beautiful form of love. In return, you > will receive untold peace and happiness." - Dr. Robert Muller > > > On Fri, Nov 30, 2012 at 2:00 PM, Tom Haws wrote: > >> Keith, >> >> What I'm maybe not understanding is why you are putting 100 lines of CRUD >> into the controllers. We have all CRUD functions in the models, and we >> simply call them in the controller functions, so that they typically are >> much shorter than 100 lines. >> >> So what I would expect is 100 model files and one controller file with a >> function each for 100 pages, assuming you want to organize it that way. I >> think another way might be to make /cp a module with each cp/page1 >> cp/page2, etc a controller file with mainly only an index function in it. >> >> Tom >> Gilbert >> >> -- >> "To forgive is the highest, most beautiful form of love. In return, you >> will receive untold peace and happiness." - Dr. Robert Muller >> >> >> On Fri, Nov 30, 2012 at 1:41 PM, keith smith wrote: >> >>> >>> Thank Tom, >>> >>> I'm already following the M-V-C like you outlined. The database is >>> normalized so no tables can be combined. >>> >>> For one table the controller contains about 100 lines of code for >>> add/edit/delete/save/list. For 50 tables that would be 5000 lines of code >>> in one controller. >>> >>> If I can figure out the routing, I can create one controller per table. >>> That is the optimum for me. Otherwise I will use includes with a switch to >>> determine what code needs to be included and run. >>> >>> Thanks again!! >>> >>> >>> >>> >>> ------------------------ >>> Keith Smith >>> >>> --- On *Fri, 11/30/12, Tom Haws * wrote: >>> >>> >>> From: Tom Haws >>> Subject: Re: OT: CodeIgniter Routing >>> To: "Main PLUG discussion list" >>> Date: Friday, November 30, 2012, 12:13 PM >>> >>> >>> Keith, >>> >>> Remember the MVC motto "Keep models fat. Keep controllers skinny." >>> Ideally the controller is nothing but a butler or a receptionist who knows >>> who does what and where to send you for what. >>> >>> Here's what would be the standard procedure for the Tempe, Arizona >>> Valley MedTrans team. >>> >>> 1. For every cp/, cp/page1, cp/page2, etc, have a function index(), >>> function page1() function page2(), etc in controllers/cp.php. >>> 2. For every table (or logical "item" of business) such as article, >>> user_account, inventory_item, bid, shipment, etc, have a file >>> models/article_model.php, models/user_account_model.php, >>> models/inventory_item_model.php, models/bid_model.php, >>> models/shipment_model.php. >>> 3. Inside every _______model.php file, have functions like >>> get_user_account($id), change_user_password($user_id, $new_password), >>> get_shipments_by_user($user_id). >>> >>> Is it possible some of your tables might be able to be combined? Would >>> you be interested in sharing part of the db schema? >>> >>> -- >>> "To forgive is the highest, most beautiful form of love. In return, you >>> will receive untold peace and happiness." - Dr. Robert Muller >>> >>> >>> On Fri, Nov 30, 2012 at 11:20 AM, keith smith >>> > wrote: >>> >>> >>> Ok, I understand. What you are talking about is what I would like to >>> do. However When I drop cp.php in the controllers directory and drop >>> pages.php in the controllers/cp directory, >>> >>> /cp/pages uses the cp.php controller. If this is what you suggested >>> earlier, I must have it mis configured. >>> >>> I appreciate your help!! >>> >>> ------------------------ >>> Keith Smith >>> >>> --- On *Fri, 11/30/12, Eric Cope >>> >* wrote: >>> >>> >>> From: Eric Cope >>> > >>> Subject: Re: OT: CodeIgniter Routing >>> To: "Main PLUG discussion list" >>> > >>> Date: Friday, November 30, 2012, 11:12 AM >>> >>> >>> You can do it that way. I always found that the CRUD wasn't just a >>> simple CRUD. The form validation was slightly different. The data >>> manipulation between models and views was slightly different. >>> Therefore, I built individual controllers, with a database table having >>> its own model extended from MY_Model extended from CI_Model. This allowed >>> me to put all of the common model functions in one file, test it, then >>> extend it further for other additional functionality. >>> >>> The CI style is less about doing it a specific way. Its not like Rails >>> where there is ONLY one way to do things. CI is flexible. >>> >>> Does that help? >>> >>> Eric >>> >>> >>> On Fri, Nov 30, 2012 at 11:04 AM, keith smith >>> > wrote: >>> >>> >>> Actually I have 50+ tables to deal with. That number will grow. I'm >>> not following what you are suggesting - "abstracting the models into a >>> MY_Model.php core file"? >>> >>> I'm thinking one controller for the control panel, and depending on what >>> the second segment is (second segment is the table name) then pull in the >>> code for managing the one table. That way I have one controller and 50 >>> includes that each contain the CRUD for it's own table. >>> >>> Any thoughts? >>> >>> I not finding much in the way of what the CI style of development is. >>> >>> ------------------------ >>> Keith Smith >>> >>> --- On *Fri, 11/30/12, Eric Cope >>> >* wrote: >>> >>> >>> From: Eric Cope >>> > >>> >>> Subject: Re: OT: CodeIgniter Routing >>> To: "Main PLUG discussion list" >>> > >>> Date: Friday, November 30, 2012, 10:47 AM >>> >>> >>> if you are adding 30+ controllers just for CRUD, think about abstracting >>> the models into a MY_Model.php core file. Keep it DRY, it makes testing >>> easier too. >>> >>> Eric >>> >>> >>> On Fri, Nov 30, 2012 at 10:33 AM, keith smith >>> > wrote: >>> >>> >>> If I can avoid modifying the routing.php script that would be great. >>> >>> I watched both video's that were on the old CI site, read lots of posts >>> on Google, and have a book that I read cover to cover. >>> >>> I have not found any real in-dept info on CI routing. >>> >>> Thanks for your help!! >>> >>> ------------------------ >>> Keith Smith >>> >>> --- On *Fri, 11/30/12, Tom Haws >>> >* wrote: >>> >>> >>> From: Tom Haws >>> > >>> >>> Subject: Re: OT: CodeIgniter Routing >>> To: "Main PLUG discussion list" >>> > >>> Date: Friday, November 30, 2012, 9:53 AM >>> >>> >>> Yeah. Keep researching CodeIgniter tutorials, because ideally, you >>> wouldn't ever need to use routes.php unless you had a need for an alias or >>> some other special occasion. >>> >>> On another note, it would be more conventional to talk to your database >>> tables in model files and then call model functions in your controllers. >>> Again, I recall watching a short CodeIgniter tutorial video that really >>> helped clarify this. >>> >>> -- >>> "To forgive is the highest, most beautiful form of love. In return, you >>> will receive untold peace and happiness." - Dr. Robert Muller >>> >>> >>> On Fri, Nov 30, 2012 at 9:36 AM, Eric Cope >>> > wrote: >>> >>> You can just put your controller "pages" in the controller/cp >>> directory... >>> >>> Then you don't have to muck with the routes... >>> >>> Eric >>> >>> >>> On Fri, Nov 30, 2012 at 9:20 AM, keith smith >>> > wrote: >>> >>> >>> >>> Hi, >>> >>> I'm rather new to CodeIgniter. I'm using version 2.0.3 and am using the >>> provided .htaccess code to remove index.php from the URL. >>> >>> I'm working on a control panel and would like to set up a controller for >>> each table to keep things simple and modular. (any feedback on a better >>> idea is much appreciated) >>> >>> I was thinking I needed to configure the controllers this way >>> >>> 1) $route['cp/pages/(:any)'] = "cp_pages"; (would contain only >>> controller code for managing the pages table.) >>> >>> 2) $route['cp/users/(:any)'] = "cp_users"; (would contain only >>> controller code for managing the users table.) >>> >>> .... other table configured with their own control panel. >>> >>> 3) $route['cp/'] = "cp"; (splash page and menu. If not logged in >>> presents the log in form) >>> >>> /cp/ gives me the splash page. so far so good. >>> >>> /cp/pages - cp controller - not what I was expecting. I was wanting the >>> index function of the cp_pages controler. >>> >>> /cp/pages/list/ - takes me to the cp_pages controller / index function >>> >>> What I would like to configure is: >>> >>> /cp/ - use cp controller >>> >>> /cp/pages/ - use the cp_pages controller / index function >>> /cp/pages/add/ - use the cp_pages controller / add function >>> /cp/pages/list - use the cp_pages controller /list function >>> /cp/pages/list/10 - use the cp_pages controller /list function with >>> segment set to 10 as starting point. >>> >>> If I'm going down the wrong path please let me know. >>> >>> Thank you! >>> >>> >>> ------------------------ >>> Keith Smith >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> -----Inline Attachment Follows----- >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> -----Inline Attachment Follows----- >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> -----Inline Attachment Follows----- >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> -----Inline Attachment Follows----- >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >> >> > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > http://lists.phxlinux.org/mailman/listinfo/plug-discuss >