CodeIgniter 2.0 and Mercurial Transition
March 11th, 2010
EllisLab has just announced they have transitioned away from Subversion to Mercurial and are hosting the CodeIgniter 2.0 source on Bitbucket.
I did a quick glance through the source and here are some of the things I immediately noticed in CodeIgniter 2.0 (this isn’t a comprehensive list, just what I find the most exciting):
- Scaffolding has finally been completely removed.
- The codeigniter directory has been renamed to core and houses most of the absolute necessities. [source]
- System-wide plugins are gone (they were mostly worthless to begin with).
- There’s a new Javascript library that features a driver system, similar to the database libraries. jQuery is currently supported but expect to see more. [source]
- A driver library has been added, to assist developer in creating their own driver-backed libraries. [source]
- You can now enable/disable individual sections of the profiler (it’s also it’s own class, rather than being part of the output library).[source | source]
- There’s a new security library that features CSRF protection and becomes the new home for XSS filtering. [source]
- The Input, Upload and XML-RPC libraries have received new features and make use of the security library.
- The Cookie helper now utilizes the Input class. [source]
- The application directory now contains a third_party directory, I presume would take the place of the old plugins directory. [source]
I’m most excited about the new Security library but can’t wait to see how this release shapes up! What are you most looking forward to in CodeIgniter 2.0?
Edit: Phil Sturgeon and Elliot Haughin have provided their run-downs of CodeIgniter changes as well. One of the biggest changes I missed was the fact that CodeIgniter 2.0.0 functionality is not guaranteed to work in PHP4 and by CodeIgniter 2.1.0, legacy features will no longer be guaranteed to work in PHP4 either.
March 11th, 2010 at 2:12 pm
It looks like the third_party directory is just a default “package” location for adding shared libraries, models, etc.
Not really used for anything just yet, but could be very handy if your third_party folder was a symlink.
March 11th, 2010 at 2:18 pm
Good call – I saw your comment on the forums about packages and went digging back through looking for what you had seen. Do you envision it being something where I could build up ErkanaAuth (all controllers, models, views, etc.) and distribute it to other people in a plug-and-play fashion via the third_party directory?
March 11th, 2010 at 2:32 pm
I downloaded the latest code and had a look through the user manual and Packages are basically modules. Here’s the relevant info from the new UM:
“Added ability to set “Package” paths – specific paths where the Loader and Config classes should try to look first for a requested file. This allows distribution of sub-applications with their own libraries, models, config files, etc. in a single “package” directory. See the Loader class documentation for more details.”
March 12th, 2010 at 12:33 am
“CodeIgniter 2.0.0 functionality is not guaranteed to work in PHP4″
Good to see that they are finally dropping that so they can start adding things like __autoload to get rid of the ugly $this->[helper|model|library]->load() stuff. That always bugged me.
March 12th, 2010 at 7:11 am
@SeanJA I don’t think they will ever go that route as that will force them to use the standard instantiation syntax ($var = new Class()) which is a far cry from CodeIgniter’s standard syntax (where everything is a child object of the CodeIgniter super global object).
March 13th, 2010 at 5:30 pm
@Michael -
Autoloading and __get would allow you to use $this->new_library directly which would be mapped to the new functionality – should they chose to go this route. You just try to instatiate the new new_class in __get – the programmer won’t feel a thing (you can wrap the new class in a try/catch block incase the class doesn’t exist.)
Of course, you could use the traditional New_Class::factory() to make a new class – better for chaining. I don’t know what advantage there is to having the CI super object.
March 15th, 2010 at 3:41 am
@SeanJA: Using $this->somelib provides much more than just PHP 4 support. Not only is it a brilliant way to keep all instances of a libratry/modal global throughout the entire CI instance, but it allows support for the wonderful MY_ prefix.
If you were to create a MY_ whatever library while using __autoload() then you would have to run through your application changing $var = new Class() and $var = new MY_Class() which defeats the entire purpose.
I am perfectly happy to keep $this->library and I very much doubt it’s going anywhere anytime soon.
@Michael: Packages doesn’t support controllers and is not really intended to be a modular system. It is more to allow multiple applications to share a stash of libraries, models, helpers, etc something that is currently not possible without some crazy Symlinking or by shoving all your code into a shared “system” folder.
It’s a shame EllisLab have not added any modular support, but EE2′s modular system is very crazy and would not work directly in the CI codebase. Derek Allard assured me that “at some point, there will be modularity in CodeIgniter, but I’m not sure when”.
Luckily Modular Separation works fine in 2.0 with a few tweaks.
March 15th, 2010 at 2:55 pm
do you know if ELab think about introduce the concept of modules like something similar to Matchbox or HMVC?
April 6th, 2010 at 9:09 am
Derek Allard said at EECI2009 (on the way to a pub, nothing official) that CodeIgniter will – at some point in time – probably have some sort of HMVC. Maybe. >.<
June 22nd, 2010 at 10:17 am
Why dont the CI team create an official ACL library like other PHP Frameworks have? Its also essential and also it can really help a lot of PHP developers out there..