Welcome Guest, Not a member yet? Register   Sign In
design philosophy: helpers,libraries, and bears oh my

This is NOT my first week using CI and YES Ive read the documentation (flow chart, mvc, helpers docs., etc...)

I just wanted to get some feedback on some of you more experienced developers on how you choose to separate your code. It seems I get stuck between what becomes a library and what becomes a helper(amongst other things). I keep redeveloping my work and keep switching reasons to do so...sometimes even models get dragged into the confusion.

Right now here is how I choose my separation:

Libraries: Anytime I am extending CI core /or/a large class of my own such as login/log out routines.
Helpers: Things that I would normally use "include()" for. smaller code for say an html form that I use repeteadly.
Models: database connectivity divided up into C.R.U.D folders I try to have all my models simply return the object they fetched and nothing more...that makes my controller have a bit more code/formatting results but I always know what to expect from the models.

I try to have all calls to models,helpers, and libraries from controllers only; that way I know where everything is coming from and don't have to chase down functions/methods; the only exception would be with one of my large custom libraries. It makes each controller a bit with conditionals (ifs/switch/etc...) but it becomes easier to read the code.

I noticed ci2.0 also has a "third_party" and "core" folder just to add to the perplexity.

I would appreciate some conventional wisdom in these regards.
What are your rules for separation?
helper: ?
library: ?
model: ?

This is how I see it.

Standalone functions (or static classes) that change some output in some way. Either by re-ordering data, transforming data, or styling data.
Example: site_url() : adds the the domain name to an url if it's not there

(Standalone) Classes that are usually not application specific.
Example: Message Library: a class that takes care of displaying messages to an user

Data Abstraction Layer that is usually application specific
Example: Page_model: contains and encapsulates your page logic and a way to access the persistent store (usually a db)

I like that you mentioned "libraries" are NOT application specific...that's a great way of looking at it... but what about when they need db connection? Do you make your db calls from right inside the library?

You can easily grab the CI superobject from inside your library and do you db stuff there. Just make sure you mention in the DOCS that the class/library is CI specific.

In this example the Message library is CI specific, but not application specific.

by grab the superobject...do you mean something like this:
$CI =& get_instance();
And yes ...never under estimate documentation!

Yes thats the CI Super object.
class Someclass {
    private $CI;

    public function __construct()

        // get the CI superobject!
        $this->CI =& get_instance();

        // now you can use $this->CI-> to get database etc.



thanks for the input n0xie & insiteFX

Theme © iAndrew 2016 - Forum software by © MyBB