0

CodeIgniter 3.0 is available in development, and has been taken over by British Columbia Institute of Technology, taken over from Ellis Labs, and has moved to CodeIgniter.com.

I am new to using PHP and databases, but after trying to figure out the best platform to work on a web project for being a basic-to-intermediate web worker, I decided CodeIgniter had the best potential for flexibility, and also a learning curve that I could handle.

Since I don't have much experience with C-like languages and programming, I still have troubles with getting the structure of the web programs (the application that runs to output the website data), because I'm just not used to the flow of a good, efficient program.

I started, trying out CI 2.1, then 2.2 after the security updates (solving the random hash keys' lack of randomness by choosing from a pretty much limited selection of numbers along a mathematical curve), and I was able to grasp the basics through the tutorials.

Aside, I haven't got my learnings for optimizing for producing a mobile-friendly site, either, although I have hopes that I can manage to use CSS to help ease that. My skills with HTML (and avoidance of JavaScript, having grown up with laggy webpages that used to bog down Netscape due to Java-related programming) eventually lead to me learning CSS.

Although various tutorials for CodeIgniter have expressed that the blurry area between model, view, and controller are mutable, I want to find some way to learn (and actually retain) "best practices" that I can also wrap my mind around.

My opening question here is:

What would you suggest as a good resource to learn, practice, and explore these skills -- and still maintain some closeness to the CodeIgniter 3.0 base?

Is there anyone working with CI (3.0 especially) who could be a resource that I could discuss questions with (that I have as I build my site) in the future? I suppose, in a way, this is asking about mentorship or peer mentoring.

Edited by Lorele

4
Contributors
8
Replies
65
Views
3 Years
Discussion Span
Last Post by lorenzoDAlipio
1

I think you have arrived to the right place. About your opening question, I am not sure what will work for you and what will not. However, when I was a lot younger than today, I wanted to learn MVC pretty bad. In fact, I was losing some pretty good sleep just by thinking about it.

One day, it just came to me and I fully understand the concept. It was an awakening to me... the attached image below is the representation of my understanding about the MVC design pattern implemented as framework.

a54990cf45de9481bf5db0f2d9242c9f

Edited by veedeoo: more info added

Votes + Comments
I think I noticed this image and extended response late, perhaps due to editing, but it was helpful!
1

DaniWeb uses CodeIgniter 2.x, as do a handful of other people here, so any questions that you may have I'm sure we can help with. I don't know anyone using CodeIgniter 3 as it's still under active development and not production-ready.

0

I think I'm looking for a little bit of a safe space to ask "stupid" questions... when I just can't figure out why a certain thing is written the way it is in code. I don't want to burden a forum with idiot questions and seem like a total fool... just a /somewhat/ fool when it comes to PHP.

2

In practice, MVC pattern is not as complicated as my drawing above. They are in fact easy to learn. The secret of learning is to go back to the basic "hello world" program introduced to us when we first met PHP and to follow the progression of PHP during its evolution.

Let us follow the breadcrumb trail of PHP in simplified approach.

Learning the advance OOP and MVC design patterns is somewhat very tricky. Remember the basic "hello world" program introduced to us?

<?php

    echo 'Hello World';

most books will tell us to give ourselves a good pat on the back and then welcome us as a newly anoited PHP programmer. Most books and online tutorials are guilty of excessively anoiting their readers. I honestly believe that this is only for the purpose of boosting the newbie's confidence. However, they were not prepared for the future evolution of PHP.

The first sign of evolution of PHP. "Let there be function" and overnight we learned how to write a function.

<?php

    function sayHello($dialog)
    {

       return ($dialog);

     }

     echo sayHello('Hello World');

Sooner than we can imagine, everyone on the web were talking about how reusable the functions they have created. Wait a minute, someone just claimed that PHP is also an Object oriented language? Huh! you must be kidding me! scream one of the Java coder.

By this time, many PHP programmers stayed with the old method of writing PHP applications, while others move on to the Object Oriented Programming. Inspite of the harsh criticisms about PHP being an OOP language, most believers have moved on to get better. Some remained in procedural because the resources in learning OOP was pretty limited and can easily confuse people who hasn't seen any codes written in OOP way.

AND then! Let there be "class, object and methods" and so there was the first class written in PHP.

<?php

    Class MyClass
    {
        var $dialog;

        function MyClass($dialog)
        {
            $this->dialog = $dialog
        }

        function sayHello()
        {

            return $this->dialog;

        }

        $myObject = new MyClass('Hello World');
        echo $myObject->sayHello();

Critics disagreed and questioned the validity of PHP self-inclusion to the higher level programming language that support OOP. Thanks to PHP's open community, their criticisms were heard. Once again, PHP came out screaming "Let there be visibility and extensibility", and on top of all these let there "Namespace".

and so the first codes were written like this..

//namespace myspace; // does not apply in codeigniter

Class MyClass
{
    private $dialog;

    public function __construct($dialog)
    {
        $this->dialog = $dialog;
    }

    public function sayHello()
    {

        return $this->dialog;

    }

}   


  Class AnotherClass extends MyClass
  {


    public function __construct($dialog)
    {

        parent::__construct($dialog);

    }

  } 

        $myObject = new MyClass('Hello World');
        echo $myObject->sayHello();
        echo '<br />';
        $childClass = new AnotherClass('Another way of  saying Hello World');
        echo '<br />';

After the stabilization as an OOP language, there was peace among critics. However, something was brewing inside the PHP community. The separation of coders and these coders became separatists with their own rights and doctrines.

Some believe there must be a separation of logic in an application, some believe there must be a separation of concerns, there are few who believe that separations must be observed in creating an application, and the rest of the coders believe procedural is as cool as OOP and MVC frameworks. Regardless of which doctrines, beliefs, and preferences have the most merits, pretty much all of them can work and the product or the output has no sign wether they are from the framework or from the middle of sphagetti codes.

Important events that were not noticed by most of us:

The birth of the logic separation was nothing but the template engine e.g. Smarty, tinyButStrong and followed by DWOO and later on Twig.

The Router and dispatcher design patterns.

The birth of rapid development frameworks. The early MVC frameworks are CodeIgniter and CakePHP.. Zend and Symfony followed later..

MVC frameworks effectiveness was borrowed from the router and dispatcher patterns. I am not really sure how many of the people who are reading this, even know what I am talking about to this point.

Having those breadcrum trails in mind, we can begin writing our basic "Hello World" program in CodeIgniter.

First, the Model: application/models/myclass_model.php

<?php

    class Myclass_model extends CI_Model
    {
        public $dialog;

        public function __construct()
        {
            parent::__construct();

         }

         public function say_hello($dialog)
         {

             return $dialog;

         }

    }     

Second, the Controller: application/controllers/myclass.php

<?php

    class MyClass extends CI_Controller
    {

        public function __construct()
        {
            parent::__construct();

        }

        public function index()
        {
            $this->load->model('myclass_model');

            $data['content'] = $this->myclass_model->say_hello('Hello World');
            $this->load->view('myclass_view', $data);
       }

   }

Third, the View : application/views/myclass_view.php

<!DOCTYPE html>
<html lang="en">

<head>
<title>Saying Hello to the world the MVC framework way</title>
</head>

<body>
    <h2> This is my first application</h2>

    <?php 

         echo $content;
        }

    ?>

  </body>

</html>

The simple rules..
1. Let model do the database query.
2. Let the view take care of the presentation logic.
3. Let the controller response to the user's requests while delegating those requests to model and passing the resulting data to the view.

You abide by those simple 3 rules, you will be able to create applications in any MVC frameworks. Some frameworks have different system in creating an application, but the logic transports are exactly the same. Even if the framework is HMVC, the the transports are just pushed one level below.

the best place to learn about CodeIgniter is the codeIgniter's wiki.

the best practices in coding is in FIG. some of the rules and suggested standards at FIG does not apply to codeIgniter. The reason is that CI wants to have an earyl PHP version fallback, and this is the reason we cannot use namespace and some of the new things coming out today like composer.

Edited by veedeoo: more info added

Votes + Comments
Absolutely stellar. Hello, Universe.
1

I have detected a missing bracket, I think, too, but thankfully this is a forum and not the crucial backbone of Google.

This was exceptionally well-written, and I feel like I could hear a Douglas Adams voice/tone while reading it.

I feel like I just got a decent history lesson, too -- which is something that you don't get in the tutorial books.

1

Guys, allow me to add something important here. CI is backward compatible with PHP4 and therefore if you want to write a PHP5 controller, then the constructor must be define and the parent constructor must be called within the controller class constructor.

e.g.

class YourApp
{
    public function __construct()
    {
        parent::__construct();

     }

 }

otherwise, this made the method index to act like a constructor

class YourApp
{

    public function index()
    {

    }
} 

and, any methods that are needed by the template can be called within the method index. Otherwise, it must be explicitly define by a route ( if the expected uri is different than the object/method convention).

class YourApp
{
    public function index()
    {
      $this->other_method();

     }

     public function other_method()
     {

         return 'something';
     }    

 } 

the above can also work without a defined route for the second method e.g. localhost/yourapp/other_method/, but this will expose your application to non-routed object/class vulnerabilities common to user profile unauthorized viewing.

The common vulnerability in auto routing in CI can be demonstrated by the codes below

class User
{

    public function __construct()
    {
        parent::__construct();
    }

    public function index()
    {
        // some default stuffs here

    }

    public function get_user($id)
    {
        // $id = some segment //
        //get user credential base on $id

     }

}     

What will happened if someone load this http://localhost/user/get_user/5 ? With few tries, they can pull out something from the application.

though PHP4 backward compatibility is the norm in CI, we CANNOT do this...

class YourApp
{

    function YourApp()
    {

    }

 }

even though it is a valid class by the rules of the old proposed coding standards of the aged PHP4, that will not and it is not acceptable in CI and any other frameworks, because of the possible Abstract classes that are maybe present in the system controller, model, and in the view..

Edited by lorenzoDAlipio: info. corrected

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.