Comments on: Ecommerce with CodeIgniter http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/ Notes by Lee Blue Fri, 26 Feb 2010 19:31:55 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: mike http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/comment-page-1/#comment-56 mike Fri, 06 Jun 2008 10:49:55 +0000 http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/#comment-56 code igniter has a config option to allow you to save sessions in a database.. code igniter has a config option to allow you to save sessions in a database..

]]> By: Artem Nezvigin http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/comment-page-1/#comment-53 Artem Nezvigin Wed, 21 May 2008 17:16:46 +0000 http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/#comment-53 Great post Lee. Things like the session handling limitation in CodeIgniter is precisely the reason why I made the difficult decision to write a PHP framework in-house and use it for our various projects. The trouble is that the more I like into any framework (CakePHP, Symfony, CodeIgniter, etc), the more limitations I find. Sure, we can dig through the framework's core code and make changes that will mold it our specific needs. But that is so unsatisfying. I fear that by the time we're done "fixing" a framework, we'll still have to show new employees which changes we have applied -- to the point where we'd need to extend the documentation a bit. If we're extending the code and extending the docs, we're ultimately writing another framework by using the old one as a base. If I were working on freelance projects that aren't too complex, I'd definitely roll with one of these frameworks. The chances of me having to make some major changes are highly unlikely for simple projects. This is where I think these frameworks shine. On the other hand, if I'm working with a team of people for 8 hours a day I don't see any reason why we can't write our basic framework and extend it based on our needs. I find that most of the code for a framework is actually writing the library, not the core features (core features being the MVC structure and loading some configs). I'm sure many will disagree with me on this issue, but the benefits of working with familiar code fine tuned to your exact needs and your team's coding style outweighs the risks. So much time is spent pulling out hair writing CSS and JavaScript that works cross browser and dealing with IE bugs that the last thing I want is a team that has to pull out hair when trying to make something work in a 3rd party framework. Great post Lee.

Things like the session handling limitation in CodeIgniter is precisely the reason why I made the difficult decision to write a PHP framework in-house and use it for our various projects.

The trouble is that the more I like into any framework (CakePHP, Symfony, CodeIgniter, etc), the more limitations I find. Sure, we can dig through the framework’s core code and make changes that will mold it our specific needs. But that is so unsatisfying. I fear that by the time we’re done "fixing" a framework, we’ll still have to show new employees which changes we have applied — to the point where we’d need to extend the documentation a bit. If we’re extending the code and extending the docs, we’re ultimately writing another framework by using the old one as a base.

If I were working on freelance projects that aren’t too complex, I’d definitely roll with one of these frameworks. The chances of me having to make some major changes are highly unlikely for simple projects. This is where I think these frameworks shine.

On the other hand, if I’m working with a team of people for 8 hours a day I don’t see any reason why we can’t write our basic framework and extend it based on our needs. I find that most of the code for a framework is actually writing the library, not the core features (core features being the MVC structure and loading some configs).

I’m sure many will disagree with me on this issue, but the benefits of working with familiar code fine tuned to your exact needs and your team’s coding style outweighs the risks.

So much time is spent pulling out hair writing CSS and JavaScript that works cross browser and dealing with IE bugs that the last thing I want is a team that has to pull out hair when trying to make something work in a 3rd party framework.

]]> By: Lee http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/comment-page-1/#comment-54 Lee Fri, 16 May 2008 00:36:17 +0000 http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/#comment-54 I have not developed a Zend Framework site with v1.5 for any of my clients. I have, however, read about the changes and was actively keep abreast of the upcoming advancements. The addition of partials, was once of the really exciting new features I was looking forward to in v1.5. The v1.0 and v1.1 versions felt really pre 1.0 to me and the 1.5 release seems like what should have been the 1.0 release. I'm not trying to belittle the work that has gone into the Zend Framework. There's TONS of functionality that all seems to work really well. Thanks for the comment! I have not developed a Zend Framework site with v1.5 for any of my clients. I have, however, read about the changes and was actively keep abreast of the upcoming advancements. The addition of partials, was once of the really exciting new features I was looking forward to in v1.5. The v1.0 and v1.1 versions felt really pre 1.0 to me and the 1.5 release seems like what should have been the 1.0 release. I’m not trying to belittle the work that has gone into the Zend Framework. There’s TONS of functionality that all seems to work really well. Thanks for the comment!

]]> By: Wil Sinclair http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/comment-page-1/#comment-55 Wil Sinclair Fri, 16 May 2008 00:28:21 +0000 http://www.refreshinglyblue.com/2008/05/15/ecommerce-with-codeigniter/#comment-55 To be perfectly honest, I'm not a big fan of this characterization of ZF (“Extreme Simplicity & Productivity”) and have been slowly replacing it on our site and elsewhere since I joined the project. Not that I don't think it's simple- it's just that simplicity is not one of ZF's strong points in a world of RoR and similar frameworks. We're actually working up towards simplicity without trading off power; that is, we plan to have tooling without strict conventions (but with easy to use defaults), an integrated experience without compromising our use-at-will architecture, and simplified support for common use cases without skimping on extension points. In other words, IMO we're challenging some of the tradeoffs that many people have take for granted in many frameworks. But there obviously *is* some tradeoff, or I'd imagine there would be many frameworks like this: development time. Quite simply, it's going to take us a bit longer to get there. :) Have you had a chance to check out 1.5? I hope our next release addresses many of your concerns; I can tell you the 'first hour' of the ZF experience has been dissected and we're trying to improve it. Also, I'm glad to see that you realize the value of ZF as a set of components that may be used with other frameworks. That is precisely why it has been designed the way it has. In any case, good luck no matter what framework you're developing with! ,Wil To be perfectly honest, I’m not a big fan of this characterization of ZF (“Extreme Simplicity & Productivity”) and have been slowly replacing it on our site and elsewhere since I joined the project. Not that I don’t think it’s simple- it’s just that simplicity is not one of ZF’s strong points in a world of RoR and similar frameworks. We’re actually working up towards simplicity without trading off power; that is, we plan to have tooling without strict conventions (but with easy to use defaults), an integrated experience without compromising our use-at-will architecture, and simplified support for common use cases without skimping on extension points. In other words, IMO we’re challenging some of the tradeoffs that many people have take for granted in many frameworks. But there obviously *is* some tradeoff, or I’d imagine there would be many frameworks like this: development time. Quite simply, it’s going to take us a bit longer to get there. :)
Have you had a chance to check out 1.5? I hope our next release addresses many of your concerns; I can tell you the ‘first hour’ of the ZF experience has been dissected and we’re trying to improve it. Also, I’m glad to see that you realize the value of ZF as a set of components that may be used with other frameworks. That is precisely why it has been designed the way it has.

In any case, good luck no matter what framework you’re developing with!

,Wil

]]>