I picked up CodeIgniter a few years back on the recommendation of a friend. At the time I had hand-coded a ton of PHP classes as the backbone of a website we were working on together. Then he said great let's put up there for the world to use. Only problem, I hadn't built any kind of interface yet.
So I started down the road of hand-coding all the web pages with the necessary forms for this site and emailed me to ask what was taking so long. He'd worked on a ton of other sites and this was one of my first full up, ready for other users, type of site instead of just screwing around out of curiosity. His suggestion was to use an MVC and CodeIgniter was one of the two he recommended. I tried CodeIgniter and never looked back. I never tried the other MVC he recommended and don't even remember the name of it anymore.
From http://ellislab.com/codeigniter:
I largely use it for forms and reporting. The primary reason I use CodeIgniter for forms is the built form validation functions. They take care of XSS cleaning, requiring a non-empty and non-NULL input field, and the rest of the obvious stuff. As far as reporting goes it is just plain nice to see the reporting wrapped in the same skin as everything else and CodeIgniter's templating makes that simple. And I usually generate the report from a form that was built in CodeIgnitier.
I don't, however, use CodeIgniter for DB interface and the heavy lifting of the site. There isn't really any CodeIgniter reason I do this. The reason is that when I learned CodeIgniter I already had all the heavy lifting code built.
The reason I continue to maintain that separation is simply that I have created and continue to maintain a large library of tools that don't need much, if any, web interface and so CodeIgniter is not part of those tools at all. These tools leverage classes I built when I was first learning PHP and have evolved over the years to be exactly what I want them to be. These non-CodeIgniter tools are where I really spend most of my time coding and as such I'm very comfortable with that library. So I build classes outside of CodeIgniter and test them; then I incorporate them - where needed - into any CodeIgniter web interface I might build later.
You might ask why I would build and test a tool without an interface and then add one. The answer is simple: the tool primarily runs via scheduled cron jobs on my Ubuntu box without any human interaction. The CodeIgniter interface - when built - is meant to allow the user (me) to change configuration values stored in the DB, account administration, and generated reports.
So I started down the road of hand-coding all the web pages with the necessary forms for this site and emailed me to ask what was taking so long. He'd worked on a ton of other sites and this was one of my first full up, ready for other users, type of site instead of just screwing around out of curiosity. His suggestion was to use an MVC and CodeIgniter was one of the two he recommended. I tried CodeIgniter and never looked back. I never tried the other MVC he recommended and don't even remember the name of it anymore.
From http://ellislab.com/codeigniter:
CodeIgniter is a powerful PHP framework with a very small footprint, built for PHP coders who need a simple and elegant toolkit to create full-featured web applications. If you're a developer who lives in the real world of shared hosting accounts and clients with deadlines, and if you're tired of ponderously large and thoroughly undocumented frameworks, then CodeIgniter might be a good fit.My applications are all still MySQL based so I still tend to build classes for handling the heavy lifting and DB interface. I then tie them into the site that the rest of the world sees and that skin the world sees is what I use CodeIgniter for.
I largely use it for forms and reporting. The primary reason I use CodeIgniter for forms is the built form validation functions. They take care of XSS cleaning, requiring a non-empty and non-NULL input field, and the rest of the obvious stuff. As far as reporting goes it is just plain nice to see the reporting wrapped in the same skin as everything else and CodeIgniter's templating makes that simple. And I usually generate the report from a form that was built in CodeIgnitier.
I don't, however, use CodeIgniter for DB interface and the heavy lifting of the site. There isn't really any CodeIgniter reason I do this. The reason is that when I learned CodeIgniter I already had all the heavy lifting code built.
The reason I continue to maintain that separation is simply that I have created and continue to maintain a large library of tools that don't need much, if any, web interface and so CodeIgniter is not part of those tools at all. These tools leverage classes I built when I was first learning PHP and have evolved over the years to be exactly what I want them to be. These non-CodeIgniter tools are where I really spend most of my time coding and as such I'm very comfortable with that library. So I build classes outside of CodeIgniter and test them; then I incorporate them - where needed - into any CodeIgniter web interface I might build later.
You might ask why I would build and test a tool without an interface and then add one. The answer is simple: the tool primarily runs via scheduled cron jobs on my Ubuntu box without any human interaction. The CodeIgniter interface - when built - is meant to allow the user (me) to change configuration values stored in the DB, account administration, and generated reports.
No comments:
Post a Comment