I’ve been thinking about the pros and cons of using CI. So far, the pros are these:

- The MVC (class/function/id) approach. This makes up 95% of its benefits to me.
- The vast amount of libraries available like the unit testing class, calender class, form validation, etc. Thats the other 5%. (Although right now I use only the validation class and might use the calender class sometime).

Here are the cons:

- Integrating my own libraries, such as a user authentication library, XAJAX, and other things are a pain.

- Not having an idea of exactly what happens to the $_POST, $_SESSION, and $_COOKIE data before they get to my code. Right now I’m struggling with a bug in my login/logout system. For some reason, $_SESSION seems to be unset somewhere. I’m pretty sure that none of my code (only one controller right now) unsets it. But still if I try to do a print_r on $_SESSION in my view, it throws a notice saying $_SESSION isn’t found.

- The system used for displaying and nesting views is seriously complicated. I just don’t understand it. It seems to be nesting ob_start() calls all through the code and I don’t know how and where it ob_end_flush()es them. For my previous code base, I would only put an ob_start() in my common.php file (called at the beginning of each file) and an ob_end_flush() in my footer.php (called at the end) and everything would work fine.

- Calling a file which contains nothing but procedural functions is very hard. Right now, I put a hook to a function which manually includes my functions.php file.

- Each upgrade of CI seems to break my old code.

- Tracing bugs is very, very hard.

- A vast amount of useless processes like writing to logs, etc, which I rarely ever use.

- All in all, it boils down to one fact that I want to have complete control and know everything about what happens when someone visits a page in my project.

Based on all these things I’ve decided that after my next project (which I’m doing right now) I’ll say goodbye to CI and build a custom framework, which uses CI’s class/function/id and a folder for controller, views and models approach. Everything else is done my way. I have a deadline to meet with this project, but if it gets too hard to continue with CI’s buggy code I might just go ahead and build it right now.

digitman - 20 November 2006 10:07 AM

- Tracing bugs is very, very hard.

- A vast amount of useless processes like writing to logs, etc, which I rarely ever use.

 

Tracking is hard and there are too much logs process ?

digitman - 20 November 2006 10:07 AM

Based on all these things I’ve decided that after my next project (which I’m doing right now) I’ll say goodbye to CI and build a custom framework, which uses CI’s class/function/id and a folder for controller, views and models approach. Everything else is done my way. I have a deadline to meet with this project, but if it gets too hard to continue with CI’s buggy code I might just go ahead and build it right now.

So you will still use CI like some of us !
Do not go so far, you could help !

GL & HF

It’s true that no one solution is ideal for everyone.  Best of luck on your future projects Digitman!  Keep popping back into the forums every now and then and say hi.

digitman - 20 November 2006 10:07 AM

- Integrating my own libraries, such as a user authentication library, XAJAX, and other things are a pain.

I actually found this quite simple - when init existed. I advocated for bring it back: http://codeigniter.com/forums/viewthread/46779/, and either way, it’s going to be a part of my CI installation.

- Not having an idea of exactly what happens to the $_POST, $_SESSION, and $_COOKIE data before they get to my code. Right now I’m struggling with a bug in my login/logout system. For some reason, $_SESSION seems to be unset somewhere. I’m pretty sure that none of my code (only one controller right now) unsets it. But still if I try to do a print_r on $_SESSION in my view, it throws a notice saying $_SESSION isn’t found.

Take a look at the Input class. You should be using $this->input->post() to get POST data.  CodeIgniter doesn’t mention the $_SESSION variable anywhere (grep is your friend) so I’m not sure why you’re having issues with that. I use the phpsession library, which uses $_SESSION with no problems..

- The system used for displaying and nesting views is seriously complicated. I just don’t understand it. It seems to be nesting ob_start() calls all through the code and I don’t know how and where it ob_end_flush()es them. For my previous code base, I would only put an ob_start() in my common.php file (called at the beginning of each file) and an ob_end_flush() in my footer.php (called at the end) and everything would work fine.

I haven’t run into that. I use the embedded views method (“method 2” on http://codeigniter.com/wiki/Displaying_Multiple_Views/) which works very well.

- Calling a file which contains nothing but procedural functions is very hard. Right now, I put a hook to a function which manually includes my functions.php file.

I would do this with a script file.

- Each upgrade of CI seems to break my old code.

The upgrade instructions are generally pretty good.. but I agree, a lot of the changes that happen that totally break backwards compatibility (eg, taking out init files) just shouldn’t happen. I’ve been fairly vocal about getting CodeIgniter opened up more, so that the community has more input on changes that are made, but so far nothing has come from it. I know some people (for some reason) actually LIKE Rick being the one and only one that has a say in where CI goes, but this is the kind of thing that happens, he makes a decision without realizing that other people rely on that functionality, and it breaks a bunch of stuff. If there was greater transparency (eg, a public repository to see changes being made) than this sort of thing could be avoided because the feedback of “no don’t take that out” can be made BEFORE it’s already been released.

It’s also my opinion that with a framework like this, any changes that break things should not be taken lightly - all effort should be made to preserve existing functionality. Something like the init method (I’m just using that as an example for convienience) being removed should not have happened because it’s so easy to preserve backwards compatibility without sacrificing new functionality (as my patch does). At the very least, things should be depreciated before being removed. Introduce the new method, deprecate the old (but keep it working), and then within a couple releases - once any issues with removing that functionality have been addressed - you can take it out to prevent bloating.

digitman - 20 November 2006 10:07 AM

Integrating my own libraries, such as a user authentication library, XAJAX, and other things are a pain.

Actually I think its exactly the opposite.  By using CI’s directory structure and format, I’ve found it great to put ‘standard’ library functionality into all of my applications and its easy to upgrade from app to app this way.  I just move the Libraries and Init folders between projects, and that’s it.  I can update the classes as needed and I don’t tend to break apps with these changes.  For me, CI’s way of handling my own libraries and 3rd party libraries that I use, is a snap and much better than me doing it manually.

Myles

digitman - 20 November 2006 10:07 AM

Integrating my own libraries, such as a user authentication library, XAJAX, and other things are a pain.

I hope to see CI bring back to the init() controller method, but I’m glad to see the “init” folder disappear. I found that way more confusing. I find case-sensitivity to be an issue that needs to be addressed. We should be able to say:

and get:

instead of

Other than that, I think it’s pretty straight-forward.

digitman - 20 November 2006 10:07 AM

For some reason, $_SESSION seems to be unset somewhere. I’m pretty sure that none of my code (only one controller right now) unsets it. But still if I try to do a print_r on $_SESSION in my view, it throws a notice saying $_SESSION isn’t found.

I can confirm that $_SESSION isn’t available in the view, as well. However, that’s not a concern because the view should never be messing with the session variables anyway.

Views shouldn’t where where their data comes from. The controller should assign all data to the view. That’s my understanding, and has saved me any headaches.

digitman - 20 November 2006 10:07 AM

- The system used for displaying and nesting views is seriously complicated. I just don’t understand it. It seems to be nesting ob_start() calls all through the code and I don’t know how and where it ob_end_flush()es them.

I’ve never used ob_start()/_flush() in my CI applications. Haven’t had any need to, so I’m curious why you have.

I use one of three approaches for nesting views:
1) load a view into a variable, and then assign it to the parent view
2) load->view() inside the parent view

3) include() the subview manually

I used to use #3 all the time, but I’ve switched to #1 for 90% of my subview loading.

digitman - 20 November 2006 10:07 AM

- Calling a file which contains nothing but procedural functions is very hard. Right now, I put a hook to a function which manually includes my functions.php file.

This is still supported, but deprecated:

And you always have the trusty include():

I’ve noticed a trend where people tend to forget about PHP being the programming language when using a framework. The framework is not the programming language. Don’t over-complicate matters for yourself. Leverage the framework, but continue to think PHP.

digitman - 20 November 2006 10:07 AM

- Each upgrade of CI seems to break my old code.

I agree that upgrading has required patience, but I’ve adopted a system that makes it relatively easy. CI 1.5 also feels very stable to me, and I personally don’t anticipate that may more changes for a while, at least.

digitman - 20 November 2006 10:07 AM

- Tracing bugs is very, very hard.

Do you monitor Apache’s “error_log” file? That quite often tells you were there might be notices, warnings, errors, etc. I only use CI’s built-in logging occasionally.

digitman - 20 November 2006 10:07 AM

- A vast amount of useless processes like writing to logs, etc, which I rarely ever use.

The logging can be completely disabled in config.php. However, I’m guessing you don’t even want to waste cycles on log_message() being called, correct? I can’t think of any other way it could be done.

I used to be an anti-cache kinda guy, but for pages with relatively static content, caching saves a lot of cycles on repetitive page loads! Not sure if you’ve used it at all.

digitman - 20 November 2006 10:07 AM

Based on all these things I’ve decided that after my next project (which I’m doing right now) I’ll say goodbye to CI and build a custom framework…

That’ll be interesting to see. You’ll be spending a lot of your own cycles rebuilding something that works like a charm for many developers. I’m not against that idea, because it took me 5 years to come around to using an open-source framework. I used to be 100% my own code, but adopting CI has been the best thing I’ve ever done.

I just encourage you to continue to evaluate this situation, and identify the real issues.

Does this mean a CI-Lite on the way?

Anyway, as a new CI User, I’ve experienced similar issues as well.  Much of it due to working with my own custom PHP Framework for the past few years.  I am so used to things working a certain way that, at times, it’s very hard to justify putting forth the effort to change.  For example, I was planning on using CI for a previous project, but I just didn’t have time to get past the learning curve in order to build a complex application.  Development work is definitely much more comfortable when you understand everything that is going on behind the scenes.

However, for my next project I will be leveraging CI and have dedicated a few hours each week towards reading the entire manual (thanks to the community for the pdf and chm versions).  I see this as an investment in a better process—similar to when first switching to CSS-based designs.  For me, its just not worth the time to try building something that may work slightly better for my individual needs, but will require additional maintenance.

I am, however, finding it difficult to piece together a complex application and I agree with many of the issues stated by digitman above.  Studying the BambooInvoice application has been very helpful, but it would be great to have more step-by-step tutorials covering advanced topics (such as authentication, third-party library integration, and best practices for views, models, code structure, etc.).  For example, it was much easier learning CSS from web tutorials, books, etc. as opposed to just reading the spec.  I am hoping to publish some tutorials after completing my first CI project.

PS.  It would be great to have something similar to the CakePHP Bakery for articles and tutorials discussing best practices.  Wiki’s tend to get disorganized over time.

’ve been fairly vocal about getting CodeIgniter opened up more, so that the community has more input on changes that are made, but so far nothing has come from it. I know some people (for some reason) actually LIKE Rick being the one and only one that has a say in where CI goes, but this is the kind of thing that happens, he makes a decision without realizing that other people rely on that functionality, and it breaks a bunch of stuff. If there was greater transparency (eg, a public repository to see changes being made) than this sort of thing could be avoided because the feedback of “no don’t take that out” can be made BEFORE it’s already been released.

Greg. I have to agree with you. But I am afraid that is not going to change.
In my opinion is a stable release should be developed by one person only and that is Rick. But after that a team of (1-2 persons) should support him with the core development and community decisions should be rather important.

I have experienced 2 opensource systems which went in totally different directions for example. The first one was a PHP CMS developed by one person only (one man show). It looked very good at first but it died in the end cause the author didn’t want any support from the community. The second one was typo3. I think everybody knows how big this one got. I think Kasper (the author of typo3) has a really big talent to motivate a big team of people and keep them all together. His vision IS the community. He enjoys bringing people together.

If Rick has a different type of attidude for whatever reason we have to accept this and either live with it or change to a different framework.

coolfactor seems to have covered just about all the points I might have wanted to make myself; but this one particularly struck me as being very significant:

coolfactor - 20 November 2006 12:11 PM

I’ve noticed a trend where people tend to forget about PHP being the programming language when using a framework. The framework is not the programming language. Don’t over-complicate matters for yourself. Leverage the framework, but continue to think PHP.

For a trivial example, I use a config file with some simple “define"s in it for setting up path names. It’s not CI config style, but it’s still php and easily understood by any other coder who might become involved.
CI is always walking a tightrope between “inadequate” on the one hand and “bloated” on the other. It’s balance seems pretty good to me.
digitman - like Derek says, come back sometime and tell us how it’s going. Good luck.

Digitman, I’m sure I’ve caught this bus before.

I never used frameworks for web development. That’s because of an allergy I
developed to fourth-generation, ‘code-generators’ I was forced to use by my employer,
way back when. (Think of COBOL code generated by a COBOL program, and be afraid).

I figured frameworks were like casinos, all shiny lights and bells and when they get you
inside they take your pants.

I develop for fun mostly and I use PHP and Python.
I’m still not sure what made me try out CI several months ago, but I’m glad I did.

Because I had a background of preferring to “control” my code, I won’t lie when I tell you
I had major slanging matches with Code Igniter. I’ve sworn at it and shouted at it.
I decided to throw it away every other morning, and every other evening I lurked
in this forum with that WTF expression on my face.

Somewhere between reading the faqing manual for the umpteenth time and BambooInvoice
for the zillionth time, a small light went on, You know, like when the Boeing’s about to land?

I realised I had been standing behind the framework, trying to push it where I wanted to go.
Now I find I’m in front of the framework, and it sort of watches my back.

Take a deep breath, maybe stop trying to push the framework?

@ Greg : Very good points you make. I recall Rick saying somewhere that CI was getting close to being feature complete (as
far as he was concerned) Maybe then he will be more amenable to making it more ‘open’ source.

shocki - 20 November 2006 01:02 PM

In my opinion is a stable release should be developed by one person only and that is Rick. But after that a team of (1-2 persons) should support him with the core development and community decisions should be rather important.

I’m not sure why you say that.. as long as the development team shares the same vision, it’s not like there is mass chaos (at least there hasn’t been in any of the projects I’ve ever been involved with). Version control is a great thing, if changes go in that people disagree with, they’re easy to revert. There is still a project leader who has final say (ie, Rick).

What I find really frustrating is putting patches in, getting no feedback, and then changes getting made that break or obsolete my patches. If the functionality gets in anyways, great, but I don’t like wasting my time developing code when there’s already similar code being developed, or a plan to implement something a certain way (that is different from my way). I’d rather hear “no this won’t go in because _____” than nothing. I think part of the problem is that there is no public repository to see what’s going on, and no public roadmap.

If Rick has a different type of attidude for whatever reason we have to accept this and either live with it or change to a different framework.

Rick seems to keep quiet on these issues though, which is why these threads get long and drawn out, and keep getting repeated over and over..

Please try the Zend Frameworks before deciding that frameworks are not for you. CodeIgniter is great, but it is too controling, like it wipes all global vars. Its main strength is that it has a lot of useful libraries for all kinds of things you’ll need and all of them are well designed. The Zend Framework doesn’t have nearly as many useful libraries, but it uses the MVC approach and you can do whatever you like, it doesn’t take over your application like CI does. You can integrate it with anything easily and do it your way. But it needs PHP 5 and is still very unstable. CI and ZF are the only frameworks I’ve ever tried, but they say that symfony, CakePHP, and Prado are also good.

I’m not sure why you say that.. as long as the development team shares the same vision, it’s not like there is mass chaos (at least there hasn’t been in any of the projects I’ve ever been involved with). Version control is a great thing, if changes go in that people disagree with, they’re easy to revert. There is still a project leader who has final say (ie, Rick).

Yes but I don’t know if the dev Team (Rick) shares the same vision. Of course there should be a project leader (Rick) who has the final say.

What I find really frustrating is putting patches in, getting no feedback, and then changes getting made that break or obsolete my patches. If the functionality gets in anyways, great, but I don’t like wasting my time developing code when there’s already similar code being developed, or a plan to implement something a certain way (that is different from my way). I’d rather hear “no this won’t go in because _____” than nothing. I think part of the problem is that there is no public repository to see what’s going on, and no public roadmap.

I agree.

Rick seems to keep quiet on these issues though, which is why these threads get long and drawn out, and keep getting repeated over and over.. smile

Yes. Let’s stop that discussion. But I am afraid this topic will come up again and again.

Final note to Rick:
Don’t get me wrong. I really appreciate what you have done already. I think most decisions you made in the past were good ones and I am really looking forward to see what direction CI is going.

Greg MacLellan - 20 November 2006 11:23 AM

digitman - 20 November 2006 10:07 AM

- Calling a file which contains nothing but procedural functions is very hard. Right now, I put a hook to a function which manually includes my functions.php file.

I would do this with a script file.

 

Why not an helper?

well said oscar spot on…

Oscar Bajner - 20 November 2006 03:18 PM

I realised I had been standing behind the framework, trying to push it where I wanted to go.
Now I find I’m in front of the framework, and it sort of watches my back.

Well stated. A good framework (particularly Code Igniter) encourages well organgized and structured code.