[eluser]dmorin[/eluser]
I think we're on the same page and in agreement on the views portion. I think most people just don't realize how much logic they put in their views. For example, I've seen apps where logic to do table stripping is re-written every time someone has a table they want to stripe which is a great example of something that should be re-factored out to keep the code DRY.
Models are not just for data access. Here is a snippit from wikipedia:
Quote:The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).
Domain Logic == Application Logic == Business Logic. So models aren't just for data access, but also manipulation, computation, and other concepts required to make the data usable to the application. Also note this following line from wikipedia:
Quote:When a model changes its state, it notifies its associated views so they can be refreshed.
In real MVC, the data from the models don't pass through the controller, they are sent straight to the view, so the controller can't implement any of the complex logic required. This isn't how views work in CI, but it still means that for MVC, most of the applications logic should be in Models and not in Controllers. I think this is one place where the CI user guide does a bit of disservice by conveying that the models are really only used for data access which is incorrect.
For libraries, I wasn't referring to the ability to have one file on a file system and re-use it for all of your CI apps. Instead, I ment that you should be able to copy a library from one CI Application/Libraries folder to another and be able to use it. That's the idea behind libraries, they're not application specific.
Lastly, I would argue that knowing if your application is running in Dev, Test, or Production is a best practice and not merely a suggestion since virtually every other framework out there supports it natively as a way to limit error messages and tune operations. That said, I understand why you wouldn't consider it needed on a beginners list.
EDIT:
An even better quote from wikipedia:
Quote:MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made.
