design philosophy: helpers,libraries, and bears oh my

[eluser]fivestringsurf[/eluser]
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: ?
???

[eluser]n0xie[/eluser]
This is how I see it.

Helpers
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

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

Models
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)

[eluser]fivestringsurf[/eluser]
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?

[eluser]n0xie[/eluser]
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.

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

[eluser]InsiteFX[/eluser]
Yes thats the CI Super object.

Code:

class Someclass {
    
    private $CI;

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

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

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

}

InsiteFX

[eluser]fivestringsurf[/eluser]
thanks for the input n0xie & insiteFX