If the CodeIgniter Community Branch was a fork...

[eluser]Phil Sturgeon[/eluser]
How do you order POST?

[eluser]DChill[/eluser]
[quote author="Rick Jolly" date="1291162981"]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.
...
The direction doesn't work for me. There are now other, better framework alternatives that share the same philosophy of simplicity.[/quote]

With all due respect, if you find the CI architecture so flawed and feel there are such better alternatives, why are you here? Didn't you choose your PHP framework based on its core architecture, or are you perhaps in a situation where the choice was made for you?

I had the luxury of directing the choice of frameworks at my job, and I chose CI because I felt it was structured in a way that worked better for my team than all the alternatives I considered. Having read a good deal of the CI source code, I'm not here to say it's perfect or couldn't use some fresh ideas, but I'm not about to grab a torch and pitchfork, either.

I think your list of suggestions is terrific, and I hope many of them can be incorporated into future revisions. However, I don't see where they are mutually exclusive with the Community Branch. If you want to develop some new architecture loosely based on CI, I don't see what's to stop you from making the next Kohana, but I'm not at all convinced that turning the Community Branch into a fork is really going to do anybody any particular good. Don't throw the baby out with the bathwater.

[eluser]Phil Sturgeon[/eluser]
Agreed. Recoding the framework should be left for projects who's aim is to recode the framework. There are plenty of those around already. Tweaking and improving should be the aim of the CodeIgniter Branch or it will just be two totally different frameworks with the same name that are totally incompatible

[eluser]TaylorOtwell[/eluser]
[quote author="Phil Sturgeon" date="1291242331"]How do you order POST?[/quote]

Not sure what you mean. It may be easier to just post some more code. Also, sorry if "model binding" is slightly confusing terminology in the CI world. That is what the term for this is called in the ASP.NET world. It really has nothing to do with "Models" in the CI sense of the word.

In core/CodeIgniter.php, I call the controller method like this:

Code:

if ($_SERVER['REQUEST_METHOD'] == 'POST')
{
   $MBIND =& load_class('Model_binding', 'core');
   call_user_func_array(array(&$CI, $method), $MBIND->bind_post_data($class, $method));
}
else
{
   call_user_func_array(array(&$CI, $method), array_slice($URI->rsegments, 2));
}

The "Model_binding" class lives in system/core. It reflects into the class and method that I pass it and examines the method parameters. If the parameter is not type-hinted then it just looks for a variable in $CI->input->post that matches the parameter name. If it finds one, it adds it to its array of data to pass into the controller method.

Things are slightly more complex if the parameter is type hinted. For example, let's our controller function looks like this:

Code:

public function do_login(User $user)
{
   // Do login stuff
}

And, let's say our "User" object looks like this:

Code:

class User {

   public $email;
   public $password;

}

In this case, the "Model binder" will see that the method requires a "User" type. So, it will instantiate a new User and get the object_vars on the instance. Then, it will map any POST data that has a name matching a property on the User object. After it maps everything, it adds the User instance to the array of parameters to pass into the method.

Let me know if that doesn't make sense!

[eluser]Rick Jolly[/eluser]
[quote author="DChill" date="1291242477"][quote author="Rick Jolly" date="1291162981"]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.
...
The direction doesn't work for me. There are now other, better framework alternatives that share the same philosophy of simplicity.[/quote]

With all due respect, if you find the CI architecture so flawed and feel there are such better alternatives, why are you here? Didn't you choose your PHP framework based on its core architecture, or are you perhaps in a situation where the choice was made for you?

I had the luxury of directing the choice of frameworks at my job, and I chose CI because I felt it was structured in a way that worked better for my team than all the alternatives I considered. Having read a good deal of the CI source code, I'm not here to say it's perfect or couldn't use some fresh ideas, but I'm not about to grab a torch and pitchfork, either.

I think your list of suggestions is terrific, and I hope many of them can be incorporated into future revisions. However, I don't see where they are mutually exclusive with the Community Branch. If you want to develop some new architecture loosely based on CI, I don't see what's to stop you from making the next Kohana, but I'm not at all convinced that turning the Community Branch into a fork is really going to do anybody any particular good. Don't throw the baby out with the bathwater.[/quote]

DChill, you are asking me to give up on CI. I have 4 years invested in it. I must use it for EE development. But most importantly, I don't like to give up.

I don't own a torch or a pitchfork. If I don't get my way, nobody will lose a head.

[eluser]Rick Jolly[/eluser]
[quote author="Phil Sturgeon" date="1291242720"]Agreed. Recoding the framework should be left for projects who's aim is to recode the framework. There are plenty of those around already. Tweaking and improving should be the aim of the CodeIgniter Branch or it will just be two totally different frameworks with the same name that are totally incompatible[/quote]
By any chance, are you a mainframe developer? Still running Windows 98? Of course not, but I'm trying to make a point. Stability is great, but CI has been stable for 4 years. At some point, all software requires a rewrite to stay relevant.

[eluser]DChill[/eluser]
[quote author="Rick Jolly" date="1291247610"]DChill, you are asking me to give up on CI. I have 4 years invested in it. I must use it for EE development. But most importantly, I don't like to give up.

I don't own a torch or a pitchfork. If I don't get my way, nobody will lose a head.[/quote]

On the contrary, it seems to me that you are an assertive member of the community with ideas to share and the will to contribute - I don't want you to give up at all. I am just trying to understand the direction you're moving in, and figure out if it's truly good for the community at large.

I see an important distinction between giving up and focusing energy in a direction that can truly bring about change. While the fork might seem productive to you now, I (as I said) am not convinced that it would pan out in the bigger picture. Then again, I might not fully understand your vision of the future, either.

You previously mentioned EllisLabs' best interests and likely courses of action, and I think your basic point was correct. They use this codebase to run their enterprise business, and as such they have a vested interest in its continued usability for their internal purposes. Of course, without that arrangement, CI would not be free to the rest of us, so let's not look a gift horse in the mouth. By the same token, enhanced performance and usability would also be in the company's best interest, as long as it didn't incur changes in their dependent code extensive enough to be prohibitively expensive.

What I perceive here is that you have already given up on Ellis' willingness to make the changes you want to see, in favor of fighting for your own sandbox where you can do it yourself. I wouldn't be so sure that they won't adopt more changes than you are giving credit for. I think this is part of their reasoning behind the Community Branch - it could be a proving ground where they can see the community's ideas worked out in actual code that they can incorporate into the official releases as they see fit. Sure, radical rewrites aren't likely to be taken in, but that doesn't mean core code can't be adapted and enhanced to make justified improvements.

If I'm off track, here, let me know - I'm only interested in pursuing the best future for CI and the community, and I'm not a certified mind reader. I would just hate to see Ellis decide there's no point in opening up the Community Branch because the community got up in arms about a fork.

[eluser]Rick Jolly[/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]

In my perfect world, I'd like php namespaces combined with php 5.3's neat class_alias() function to enable transparent class extensions with a cascading file system. But there are many different implementation possibilites, and I'd welcome a debate of several proposals.

I'm sure you know this, but basically autoloaders require namespaces or a naming convention to work. The PEAR/Zend naming convention of Dir_Dir_Class for class names is almost standard. Namespaces are cleaner: dir/dir/Class.

Autoloading could even work for CI as-is. CI class names are now prefixed with the naming convention "CI_". So, within the autoloader, if a class name is prefixed with CI simply call the CI Loader class' "_ci_load_class()" method.

[eluser]Rick Jolly[/eluser]
DChill, I could be wrong about what I perceived as Ellislab's intention for their community branch. I would love to be wrong.

[eluser]Phil Sturgeon[/eluser]
[quote author="Rick Jolly" date="1291247957"][quote author="Phil Sturgeon" date="1291242720"]Agreed. Recoding the framework should be left for projects who's aim is to recode the framework. There are plenty of those around already. Tweaking and improving should be the aim of the CodeIgniter Branch or it will just be two totally different frameworks with the same name that are totally incompatible[/quote]
By any chance, are you a mainframe developer? Still running Windows 98? Of course not, but I'm trying to make a point. Stability is great, but CI has been stable for 4 years. At some point, all software requires a rewrite to stay relevant.[/quote]

That is a good point, but consider this.

EllisLab have been good enough to say "Ok, if you wan't to make improvements go ahead. We'll make this branch so everybody can contribute ideas and suggestions to the same place and we'll take those that we see as a benefit to our product".

This is more than has been done before as in the past people have just got in a huff and made their own forks. Admittedly that is slightly what Fuel started as, and is exactly how Kohana started.

The problem is if the community start drastically changing everything then how can EllisLab be expected to merge it? It would just become a totally uncompatible fork that might as well be third-party without a "EllisLab" badge, which you can do right now (and many are).

If we change everything, autoload everything, recode all the libraries, make it all HMVC, etc then they would have to totally recode ExpressionEngine. You know as well as I do that would be a nightmare :gulp:

I don't believe any drastic structural change is needed to improve CodeIgniter. We can start small with useful, iterative improvements and see where it goes. This is a great change for CodeIgniter, but I really do think expectations need to start low and reasonable for this to work out.

Not being contentious, I'm trying to explain my view on this discussion. Please do not respond with negativity or assume I am trying to control anything :down:. That said I do know several of the other Deputies feel similarly.