If the CodeIgniter Community Branch was a fork...

[eluser]Rick Jolly[/eluser]
From an update on the "Official CodeIgniter Community Branch":

Since we are not ready to reveal its name, we were simply trying to avoid calling it something lame like “CodeIgniter Community Edition”, and in haste chose “fork”. We’ve changed the wording in this article to more accurately reflect the intent, using “branch”

Now a branch is something designed to be merged back into the code base. So I don't see any fundamental architectural changes in the future. Nothing that would break backwards compatibility. I suspect the purpose of the Official CodeIgniter Community Branch is to add features and refactor existing code, not improve the architecture.

This strategy makes sense for Ellislab. Their CI-based products continue to work unaltered, and they benefit from new features built and thoroughly tested by the community.

The direction doesn't work for me. There are now other, better framework alternatives that share the same philosophy of simplicity.

So maybe it's pointless to voice my top 5 architectural changes, but here they are:

1. PHP 5 autoloading. So long $this->load->something(). The loader class served PHP 4 well.

2. Common consistent convention for drivers using interfaces that transfers to session, database, cache, etc.

3. Generic solutions:
a. Module system instead of single-purpose solutions like CI 2 packages.
b. Validation library that works on any array, not just $_POST
c. Pagination library that works on any collection, not just database results.

4. No more helper and library distinction, only classes. Helpers become static classes.

5. Depreciate some CI libraries. Focus on CI strengths and support optional bundling and interoperability of some best-of-breed libraries like HTML Purifier, Swift Mailer, Doctrine and others.

[eluser]Michael Wales[/eluser]
Many of the ideas you listed were discussed when Phil Sturgeon setup that chat session last week, ideas #1-4 specifically.

[eluser]Rick Jolly[/eluser]
[quote author="Michael Wales" date="1291170340"]Many of the ideas you listed were discussed when Phil Sturgeon setup that chat session last week, ideas #1-4 specifically.[/quote]
Yep, #1 was deleted from his document

[eluser]Crimp[/eluser]
Branching works both ways. My vote is for a branch.

I do, however, agree with all your points, 1-5 and a-c.

For a purification-heavy forum I wrote recently, I used HTML Purifier with CI.

So your point number 5 makes some extra sense.

This point also relates to an earlier comment I made when they ditched "plug-ins" and bundled everything into "helpers".

My point then and now is to better support the architectural "idea" of using what you describe as best-of-breed libraries with CI.

[eluser]Phil Sturgeon[/eluser]
[quote author="Rick Jolly" date="1291177348"][quote author="Michael Wales" date="1291170340"]Many of the ideas you listed were discussed when Phil Sturgeon setup that chat session last week, ideas #1-4 specifically.[/quote]
Yep, #1 was deleted from his document[/quote]

It was removed pending discussion, as nobody actually detailed how auto-loading would work. What's are your ideas for the implementation?

[eluser]techgnome[/eluser]
I'm curious about that as well. I don't necessarily always want everything to load everytime. Call me a control freak, but there are somethings I want to have control over. And that includes loading only the things I need when I need them. Loading models & libraries still needs to be selective.

-tg

[eluser]TaylorOtwell[/eluser]
[quote author="Phil Sturgeon" date="1291219362"][quote author="Rick Jolly" date="1291177348"][quote author="Michael Wales" date="1291170340"]Many of the ideas you listed were discussed when Phil Sturgeon setup that chat session last week, ideas #1-4 specifically.[/quote]
Yep, #1 was deleted from his document[/quote]

It was removed pending discussion, as nobody actually detailed how auto-loading would work. What's are your ideas for the implementation?[/quote]

Beyond auto-loading, re-working some things to use Dependency Injection (via constructor injection) would really improve the framework, IMO. I've already changed CI to do this but it required a few lines of hacking in some Core files and writing an IoC container for CI.

But, it allows you to use type-hinting in your constructor parameters and let the DI framework inject those dependencies for you. So, my controller constructors look like this:

Code:

public function __construct(IFoo $foo)
{
     $this->foo = $foo;
}

And I setup which implementation of IFoo the system should use in an application/config/dependencies.php file using the IoC container like this:

Code:

CInject::container()->bind('IFoo')->to('Foo');

Now, everytime CI instantiates a controller that needs an "IFoo", it will inject an instance of "Foo" (and it will resolve Foo's constructor dependencies as well). This allows for really flexible code and switching implementations easily.

Also, adding ASP.NET MVC style "Model Binding" would be a big plus. I've also added this myself, but it required some more hacking. Basically, on an HTTP POST, bind the POST data to the controller function parameters if the names match, so that if I have a function that looks like this:

Code:

public function login($email, $password) {}

And if my form contains an "email" field and a "password" field, the values will automatically be passed into the function. Or, you could even use type hinting in the function and bind the POST values to an object's properties. I use reflection in conjunction with my IoC container to accomplish this.

[eluser]Phil Sturgeon[/eluser]
[quote author="techgnome" date="1291233042"]I'm curious about that as well. I don't necessarily always want everything to load everytime. Call me a control freak, but there are somethings I want to have control over. And that includes loading only the things I need when I need them. Loading models & libraries still needs to be selective.

-tg[/quote]

You are confusing CodeIgniter autoloading with PHP autoloading. Easy to do, they are called the same thing.

CodeIgniter Autoload = Always load X on each page call.
PHP Autoload = Lazyloading = Load this when I ask for it, without me actually loading it.

PHP autoloading works like this:

Code:

$user = new User($id);

Trouble is, we don't know if that is a library or a model, so we'd have to check both folders. Which is more important? Should that also be added to the $this-> superglobal so you can use it in "the CI way" and have it loaded once throughout your application?

The autoload approach and the CI approach are fundamentally pretty different so it would be tough to implement without changing entirely how the framework works.

[eluser]n0xie[/eluser]
[quote author="TaylorOtwell" date="1291233998"]
Also, adding ASP.NET MVC style "Model Binding" would be a big plus. I've also added this myself, but it required some more hacking. Basically, on an HTTP POST, bind the POST data to the controller function parameters if the names match, so that if I have a function that looks like this:
[/quote]
You mean Register Globals?!

[eluser]TaylorOtwell[/eluser]
[quote author="n0xie" date="1291240619"][quote author="TaylorOtwell" date="1291233998"]
Also, adding ASP.NET MVC style "Model Binding" would be a big plus. I've also added this myself, but it required some more hacking. Basically, on an HTTP POST, bind the POST data to the controller function parameters if the names match, so that if I have a function that looks like this:
[/quote]
You mean Register Globals?![/quote]

No. What I'm talking about essentially works the same as CI already works on a GET request, it just does similar functionality for POST requests. The only difference is it is intelligently mapping POST data (via the CI Input class) to the function instead of URI segments.