Compelling Reasons to Switch to CodeIgniter

[eluser]IgnitedCoder[/eluser]
Hi Guys,

As a CI developer I often forget some of the most compelling reasons I switched from pure PHP and Dreamweaver to CI. I now find myself in a situation where a client has developers who built a pretty good system using CodeCharge which as you may or may not know is a visual wysiwyg development tool, it includes wizards for just about everything. This certainly makes life easy, however the code it produces isn't very clean but one would ask if the system works why do we need clean code? Anyway I digress from the subject...

I spent approximately 2 hours going over why codeigniter would be the better choice for our future development efforts. What we are doing is providing SaaS and the old, I should say, current application was developed in CodeCharge to which another developer added a bunch of includes for FPDF lib. Don't get me wrong the application the have works but it won't be easy to scale up because of generated code, second I've never seen CodeCharge used in a team development environment. Its clearly not MVC which means we have files all over the place, no detailed and structured view of whats where.

As I said I spent a good few hours going over the reasons to switch to CI and it fell on argumentative ears to say the least. Now heres the thing, the CIO calls me back and says come back gives us more reasons why we should be switching to CI. The developers tell me that they saw nothing CI could provide that they didn't already have in CodeCharge.

For one thing, CodeCharge doesn't seem to be a Team Development Suite. Second I think "personal opinion here" that these guys are a little afraid of hand coding anything. Why should I hand code anything when I can simply design it using a GUI and I have the code then I can just include other functions using a include statement? "I was asked this about 10 times".

I finally asked them to show me their current applications object model... The answer shocked me. "Well we don't have a object model so to speak" but we can show you our screens which are out objects, you can look at he HTML to see our model. Ok granted that was a trick question on my part and probably not as well placed as it should've been, but, I was hoping to make a point about architecture that failed miserably. - LOL

Anyway so now here I am once again having to make a long and technical proposal for CI to developers who "I think, personal opinion" are so embedded in the use of a GUI and they fear that they might lose control. Actually I've seen it before, developers hold onto to technology out of fear, not because its good technology but because they know it well, its helped them build a solid reputation in the company as the goto guys, the heros who solve it all.

Along comes this new guy "me" with new ideas and as much as they would like to show the CIO and Board they are willing to do what it takes to scale up, they will find every reason why any new suggestions for technology should not be changed. I think its almost and unconscious defensive mechanism... I'm no psychologist but I've been doing this a while and I've seen it happen more than once.

Ahhh sorry for the really long story here guys but I really wrote this post to get advice from the group on what I can say to get these guys to switch to CI which is clearly the more logical route to take for the company. Oh I even explained that the existing code in the includes could easily be ported and re-used in CI controllers, again it fell on argumentative and fearful ears.

Any comments and suggestions are welcome... even those critical of my opinions.

Thanks,
Brendan

[eluser]Jelmer[/eluser]
Just a short suggestion: maybe start off with explaining why they need to do things differently in general. Ie. Good programming prevents mistakes, makes bugs more easily fixed, allowes for greater scalability, etc...
Start off explaining why their current way has its limitations and then explain how certain frameworks and the MVC architecture can help them in general. Bring CI into the mix only after they already get why a change is needed, and then explain how CI aids in the implementation of the advantages you've already explained.

That prevents a direct CodeCharge vs. CodeIgniter comparisson, which seems to me pretty much apples and oranges. And it should bring the focus more to doing things one way or another and the (dis)advantages of both methods. If you can't convince them they should take ownership of their code and know what they're doing, you're not going to convice them about CI.
But once you have, CI should start to look very appealing.

[eluser]Keyur Shah[/eluser]
Hey,

I'm in the same boat with some of my own scripts. I am not in a team environment, I am the only developer. But I am wanting to switch from CodeCharge to CodeIgniter for similar reasons.

Some of my reasons are:

Consolidating queries for multiple pages into singular model pages
Using the data from models for multiple views
Easier to separate data from views
Can move data around the pages easier (not limited by Codecharge's layouts)
Can't stand the CodeCharge editor (much rather prefer VIM)


The main issues that I have in switching away from CodeIgniter is editable grids. I have not found an easy solution yet for creating these types of pages unfortunately. That is what I am researching right now. I love the easy to create sorting/pagination features.

For regular application development, it's a no brainer, but for grids and editable grids, it is difficult until I find an easy way to create these.

Please keep us updated on how your change progresses.

[eluser]skunkbad[/eluser]
Does CodeCharge make code that is secure? CI has great form validation and security. That might be a selling point. New PHP programmers are usually really bad at making secure scripts, ya know?

By hand writing code, code style can be maintained, and code itself can be more easily maintained. Coming back to a CI app after 6 or 12 months, and you will still have code that you can recognize, edit, etc.

Optimizing code has performance benefits, both server side, and also client side. This is probably not something that CodeCharge cares too much about.

That's all I could think of.