When to load what?

[eluser]Kola[/eluser]
I'm still rather new to CI so hopefully one can help me out. My idea is to build my website around libraries, which will look something like this:

Core.php - all core functions, inherited by almost any sub-library
Auth.php - user functions
News.php - news

etc etc. First of all, what i want to achive, is a system which is more module based. So I can basicly plug 1 system in and kapow, I have a working news system. How does most people get around this?- especially the administration part which I haven't figured out yet (think my initial plan is to make a set of functions in a file, which is then incorporated into a administration panel or something).

But yeah, how do you guys get around this?

Secondly, in my file Core.php I have a constructor instanciating the CI framework ($this->CI =& get_instance() - am I supposed to do this for the sub-libraries aswell then?

[eluser]WanWizard[/eluser]
It is possible to do it this way, altough you deviate from the CI MVC setup in that you intend to 'misuse' libraries as generic controllers.

It is better to go for a modular approach, and implement your site components as modules that you can call from a page controller when you want to add functionality. There are several CI extensions around that provide support for modularity. Search the forum or the wiki.

This is how ExiteCMS works, you create a module for a specific function (p.e. a slideshow), drop it into the modules directory, and call it from a page. A module is basically a self-contained mini-CI application, it contains all controllers, views, libraries, models and assets to provide said functionality. The only difference is that a module controller (in my case) doesn't generate a full page, but only a partial (in ExiteCMS terms a page element, PyroCMS calls it a widget) so you can plug it into an existing page.

[eluser]Kola[/eluser]
Wouldn't there be a fair ammount of rewritten code, if each module has everything it needs?

With regards to the MVC concept, yeah you deviate from it, but as far as I've seen, as soon as you make a library, you do just that. Which confused me really. Most module functions will be contained in the library, controllers will only serve as a media to reach those functions in the library? Or am I wrong?

[eluser]WanWizard[/eluser]
That depends on how modular you are (or want to be).

ExiteCMS modules are specific to provide a single functionality, so there is no real overlap. Besides that, modules can call other modules.
For example, I have a module that provides PM functionality. The workflow module can call a model in the PM module to generate a PM informing a user a task has been completed.

With regards to libaries, that's the beauty of CI. It doesn't force you into any kind of structure, like many other frameworks do.

If you feel comfortable with your solution, by all means, go ahead. The only change to the "traditional" MVC approach is that your library methods are going to call models, instead of your controller.

[eluser]Kola[/eluser]
Again, new to OOP and CI so my experience in either is limited. Always been the type of coder going by on what I knew and workarounds (not necesarily the best ways). Basicly I'd love to stay in the MVC pattern, but I have a hard time getting my mind around how I need to build it up

Basicly, what needs to be where and which functions do I need in which library, and how the workflow between the libraries should be. But yeah, guess it's just a matter of looking at more code.

[eluser]WanWizard[/eluser]
Think of controller as containing the workflow to get from the request to the output.

As to what belongs where, a simple rule of thumb:
- is the method unique? if so, it belongs in the controller
- is the method generic? if so, put it in a library so it can be reused
- does it deal with data (fetching, preparing, storing, etc), it belongs in a model

As said, there are no strict rules. I sometimes have database I/O code in my controller, because I can't be bothered to create a model for a single method that is only used by one controller that calls it once.