[eluser]BrianDHall[/eluser]
With some enhanced understanding of what on earth is going wrong with this discussion, I'm returning to the originating post and hope I can clear some things up.
This might be considered a deviation from my earlier post and not be strictly about 'porting', but it reflects newfound understanding.
[quote author="Knitter" date="1254274927"]I'm now trying to get all this into code, so today's question is: Where do I put my application classes and how does CI know about them, or manages them?[/quote]
OK, here is where you start to go wrong. CI is, and this will sound strange, not concerned with your applications classes.
...yes, that sounds weird, but for you and your pre-existing classes its true.
In CI the $this->load functions are all specific to certain CI classes that extend a base class that is part of CI. They instantiate one instance of the thing being loaded and assign it as a member object of the CI super-object for easy reference with $this.
If you want to use your own classes and don't mind that they don't have certain built-in methods, properties, and functions provided by CI then CI doesn't need to get involved at all!
This is a big upside of CI, and it's such a big deal that its hard to realize it - unlike other frameworks and systems, CI does very little and gets out of your way. You can for instance just wrap CI around a complete system and use CI for nothing but routing if you wanted. This allows you to drop in Zend framework library objects for things like flickr or twitter or whatever and CI doesn't seem to mind at all.
If you want certain classes to be autoloaded in the sense you mean it, I have a trick for you. Make a 'library' class as the manual instructs, and autoload it in your config.php file. In that library include whatever you want to include - have it be a script that includes all files in a specified directory, or however you want to handle it! include() menu here, and then anywhere else you should be able to call new Menu($params) and it Just Works.
Also, extending model doesn't actually do very much. If you want to use your own pre-existing model knock yourself out. You can never use a model in CI and it won't complain - you won't even lose any functionality! I really like DMZ and how it handles ORM, and you could still integrate your system with it...but its opinionated in ways that might not work for you. So feel free to just include that non-CI model and load it up and go!
Quote:But CI puts me in the position where I don't really know how to create my application, it tells me that the model is just a collection of classes that only have data, and data access if you considered accessing the DB as part of the model, and that a controller is an all mighty class/entity that controls everything.
I think a lot of MVC talk is phooey, which is why I like CI. It ought not be so damn opinionated, and it actually isn't when used that way.
Controllers and functions are CI's core system, and they control URL routing and program flow. How you work beyond that is up to you entirely. You need never use a CI view or model if you don't want to.
Now, to individual items...
Quote: So:
- How do I access one controller from the other, or, send events to listening controllers?
CI does not offer this or do this. Controllers are to be...well, sort of islands unto themselves, with no direct interaction or co-operation amongst themselves. I often use only 1 controller because I have little reason to split the file up into so many distinct pieces.
The controller in CI just 'controls' what HTTP requests invoke what, and they load up some of the core functionalities of CI and enable its various helper classes and such.
If you don't want to they need do nothing else. If you want your controllers and functions could be little more than routed calls that control the instantiation of certain objects that take it from there.
Quote:- Where do I put my support classes and interfaces and how does CI load them? Must I do all the work myself and go around what CI does?
It really depends. If your existing classes do all the work CI does, then you don't really need CI. Use only what you need like routing if you want, but it becomes debatable if CI is really doing very much for you. Managing the separation and organization of things softly is really most of CI's job as a framework.
Quote:- If, for example, I was building a contacts application I would create the ContactManager class, that would hide all the functionality of my application, I would then create the necessary views to it, can I do something like this in CI, or am I stuck with the "one page-one controller" thing?
Indeed, one-page is one controller, but this is really a semantic issue. CI takes a page and routes it somewhere - it separates things into controllers as "groups of related pages" and functions as the actual pages themselves. The models then handle the data manipulations of the application, and views handle display. That's all - they are very lightweight.
Quote:- Can I have a middle controller from where all my controllers extend without having to modify CI? I have a piece of code that all controllers should have, can I create an abstract controller that is going to be the parent for all my controllers? Or must I use things like URI mapping and extending base classes from CI?
The MY_Controller, as mentioned, is kind of magical in ways and I think this one is one area where the question is answered sufficiently.
Just so you know, I do most of my work in CI with one controller and no MY_controller, as I keep the 'common to all pages' code in the constructor. If my app gets big enough to need splitting into different controllers then to avoid copy/pasting I will use a MY_controller for the universal code.
