Why isn't CodeIgniter a genuine MVC?

[eluser]WanWizard[/eluser]
@craig.hoog,

a) is not an argument at all.

Any application has reusable components, it doesn't matter what you call them. If they don't, the applications are either extremely simple, or violate the DRY principle bigtime! Reusable components are not relevant in an MVC design pattern discussion.

b) MVC !== HMVC. so agreed it's a bogus argument.

As to Shawn's blog post, he absolutely raises some valid points, points that made me move on to a framework that better suited my needs.

But that doesn't mean CI is dead. It's still a very easy to learn framework, with a large community and excellent documentation, and can be used to create reasonably sized web application with relative ease.

@Dan Storm,

For me one of the big annoyances is the lack of strategy, project management and roadmap. Yes, there is a lot of activity visible in the github repo. But it doesn't seem to be guided towards a common and predefined goal.

As a third party developer it means I haven't been able to do any major development for about a year now, because I don't have a clue where the framework is heading. I gave up trying to stay compatible with what's happing in the repo after the umpteenth time stuff broke after a major change in the core. I'll wait for an official release I can work on.

As an application architect and developer, I noticed a few years ago that the more complex the application became, the more I was slowed down due to missing core components (like HMVC), the singleton design, and the PHP4 based core architecture.

Which is why I now use another framework (no, not the one Shawn shamelessly plugs ) for my development, and only use CI when I have to maintain existing applications, or for occasional client work that has CI as a requirement. And I have to say my production rate went up dramatically.

[eluser]craig.hoog[/eluser]
@WanWizard
Can you tell me what framework it is? I'm quite interested.
The one Shawn was promoting looked decent, but I don't want to dive into something new at this point. That said, I used to be die hard for CakePHP and made the jump to CI, so it wouldn't be the first time.

[eluser]CroNiX[/eluser]
He is respectful and won't really say it openly on the CI forums, but I will: http://fuelphp.com/about

[eluser]craig.hoog[/eluser]
[quote author="CroNiX" date="1337105942"]He is respectful and won't really say it openly on the CI forums, but I will: http://fuelphp.com/about
[/quote]

Thanks for the information. Have definitely seen Fuel before, but have not tried it out.

I am launching into a large scale project right now with CI - this is most likely to determine whether or not I use CI for the rest of my "career" or not.

</forumSteal>

[eluser]TWP Marketing[/eluser]
I've been following this thread with interest since my business fits the 'small' site model, rather than large projects. CI fits my needs now, but I have to agree with WanWizard and Dan Storm about the lack of public direction for future versions. My repo from Github works, for a while, and then it breaks when a change is applied. That makes me back away and wait for a stable release, as WanWizard related.

The direction of CI does seem to be, at least partly, driven by the needs of Ellislabs and their products. Which is a problem in terms of offering a general purpose framework.

I participate in this forum as a source of information on CI coding practice, and I note that those who use multiple frameworks are bound to compare their tools (no pun intended). The blog by Mr. McCool is a case in point. None-the-less he does make a valid point about the lack of a (visible) direction to CI's future development. I see requests on this forum for a more public discussion of plans for CI, and I also see an uncomfortable amount of 'smack down' of dissenting opinions by the more senior forum members. That seems counter-productive...

This reply is moving this thread outside of the original topic, so I'll make a recommendation:

I'll go out on a limb and suggest that at least a thread, if not a new forum, be created to accept AND DISCUSS recommendations for development direction. I acknowledge the statements from the developers that such input 'should' be directed to the Github arena, but I, personally, find Github to be unsuitable for discussions. Not everyone uses Github. The number of forks of the Github code is relatively small, which tells me there are few people who have the time to involve themselves at that level. I want to see a broader picture of CI's future development.

[eluser]craig.hoog[/eluser]
Not to spin this off even more, but what is the main issue with just using a version of CI to build a project and not updating it?
Is it just a security concern? I look at something like Bamboo Invoice and I assume they aren't going to keep updating their core CodeIgniter version anymore?

[eluser]WanWizard[/eluser]
From an application point of view, you probably can get away with it as long as you don't do major work on it (that requires features or bugfixes only present in newer releases) or if it's not that old that you hit PHP issues.

I my case I'm a third party developer, which means my product must work with (preferably) all recent versions. I am now at a point where I have to maintain 3 different codebases for CI 2, CI 2.1 and CI Reactor. And believe me, that is not funny.

And what worries me is that since CI moved to Github, the code is fully in the hands of the community. The last commit from Derek Jones was on Oct 21, 2011, all others are from community members. They are making a community version of CI. Also, I see continues commits in the 2.1-stable branch, making it not very stable imho. And probably quite different from the 2.1 official CI release.

Parallel to that, Ellislab maintains their official CI release train, developing it seperately for their internal needs, and cherry picking from Github what they think should be in the official core.

So, what exactly should I develop for? Please tell me, because I don't know.

[eluser]TWP Marketing[/eluser]
@craig.hoog
For me, it's a matter of major changes in php, not in CI, such as php4 deprecations. Were it not for that, I have (had) sites which ran just fine under CI 1.7x/php4, but which required re-writes when the client's host dropped php4 support. While good for my business, rewrite was not required by a change in CI core functionality.

The blog post referred to earlier made too big a deal of frameworks which don't keep up with the bleeding edge of php. I think CI's 'requirement' of php 5.2 is just fine, for now.

Unless my client job specs request functionality from php 5.3-5.4, my CI code will work. It's my job to tell the client why and how much their specs will cost them, or to talk them out of it. Note that CI code under php 5.2 will run under php 5.3+. And remember that CI is just php. I can still write a library/helper/module which uses those bleeding edge features and interfaces to CI coding based on php 5.2. Sure it would be nice if the CI core supported the higher php version, but it is not a show stopper.

And I think CI IS an MVC framework... Just to keep on thread <g>