mirror of
https://github.com/bcit-ci/CodeIgniter.git
synced 2025-02-20 11:13:29 +08:00
Corrected a link to Jedd's header, footer and menu on every page. And - formatting for h2 headers.
parent
8e7c8d1bfc
commit
2afd994f12
@ -3,9 +3,8 @@ This page describes a standard feature of the CodeIgniter framework - the abilit
|
||||
Take care - these instructions are for CodeIgniter **1.7.x** - the **2.x** release sees MY_ class extenders relocated to app/core - see the relevant documentation for 2.x. CI 2.x controllers also extend CI_Controller instead of just Controller.
|
||||
|
||||
|
||||
[h2]
|
||||
Overview
|
||||
[/h2]
|
||||
## Overview
|
||||
|
||||
We assume here that you have an understanding of CI and MVC fundamentals. You will have read through the [User Guide]("/user_guide"), especially the sections on [Controllers]("/user_guide/general/controllers.html") and [Models]("/user_guide/general/models.html").
|
||||
|
||||
The subject of extending core controllers is discussed briefly in a few places in the manual - specifically in the [Core Classes]("user_guide/general/core_classes.html") and [Creating Libraries]("user_guide/general/creating_libraries.html") pages.
|
||||
@ -14,12 +13,8 @@ The **intent** of extending the core Controller is to provide methods and attrib
|
||||
|
||||
Finally, it's assumed that you have an application that does *something* - it doesn't matter what, merely that you have an existing Controller that we can work with here.
|
||||
|
||||
## Creating the MY_Controller file
|
||||
|
||||
|
||||
|
||||
[h2]
|
||||
Creating the MY_Controller file
|
||||
[/h2]
|
||||
Extensions to the core libraries are placed in **application/libraries** and the file name is determined by adding the **$config['subclass_prefix']** to the core library name.
|
||||
|
||||
The $config['subclass_prefix'] variable is set in **application/config/config.php** and by default it is set to '**MY_**'. You probably don't want to change this unless you know what you're doing (and if you know what you're doing you're probably not reading this guide).
|
||||
@ -43,12 +38,7 @@ class MY_Controller extends Controller {
|
||||
|
||||
Save and quit. Obviously this file doesn't actually *do anything useful* but we'll get back to that in a minute.
|
||||
|
||||
|
||||
|
||||
|
||||
[h2]
|
||||
Modifying your existing Controller
|
||||
[/h2]
|
||||
## Modifying your existing Controller
|
||||
|
||||
We'll now modify one of your Controllers to work via the MY_Controller. The following code partial is obviously not a fully functional Controller - I'm just showing enough so you know what you have to change. Here we're using the Controller **Forum**. CodeIgniter encourages users to stick with the PHP4 (constructor name is the same as class name) syntax, but both formats are shown here.
|
||||
|
||||
@ -94,11 +84,7 @@ Now test your application - it will work exactly the same as it did previously.
|
||||
|
||||
All we've done here is inserted this **MY_Controller** class in between your normal Controller and the CI Controller class. Previously your Controller was descended directly from the CI core. This is basic OO theory, but if you're not familiar with that then a ludicrous analogy might be that we've just inserted a new generation between you and your dad - with your dad suddenly becoming your grand-dad. You have still inherited the blue eyes and sparkling wit, but it means you can also now inherit (once you create them!) things from this new intermediate ancestor - such as curly hair or date formatters.
|
||||
|
||||
|
||||
|
||||
[h2]
|
||||
Putting useful stuff in MY_Controller
|
||||
[/h2]
|
||||
## Putting useful stuff in MY_Controller
|
||||
|
||||
Usually people are looking for a way of making functions accessible across all their Controllers - and so we'll make a very simple function in your **MY_Controller** to demonstrate how this can work.
|
||||
|
||||
@ -153,10 +139,7 @@ class MY_Controller extends Controller {
|
||||
|
||||
```
|
||||
|
||||
|
||||
[h2]
|
||||
Using a MY_Controller method from your Controller
|
||||
[/h2]
|
||||
## Using a MY_Controller method from your Controller
|
||||
|
||||
The pretty_date() function above is particularly useful for ISO8601 timestamps that come in from EXIF information, for example. We'll just use a hard-coded input string here.
|
||||
|
||||
@ -177,11 +160,7 @@ In your view you can now **echo $friendly_date** - so go and make that change to
|
||||
|
||||
Impressive, eh?
|
||||
|
||||
|
||||
|
||||
[h2]
|
||||
Final notes on this method
|
||||
[/h2]
|
||||
## Final notes on this method
|
||||
|
||||
This is a fairly trivial example of what you can do with MY_Controller - most people would put a function like pretty_date() into a helper, as it requires no database access, and is only needed for views that have to generate a pretty date from an ISO8601 one.
|
||||
|
||||
@ -191,4 +170,4 @@ More often you would use a MY_Controller for 'on-every-page-load' activities lik
|
||||
**o** applying an authentication layer - often tied in with Session data,
|
||||
**o** generating common view partials (headers, footers, menus).
|
||||
|
||||
As an example of the last one there, have a read of Jedd's [header, footer and menu on every page]("/wiki/Header_and_Footer_and_Menu_on_every_page_-_jedd/") article.
|
||||
As an example of the last one there, have a read of Jedd's [header, footer and menu on every page](/wiki/Header-and-Footer-and-Menu-on-every-page---jedd) article.
|
Loading…
x
Reference in New Issue
Block a user