

jlp





Senior Member

Threads: 151

Joined: Sep 2014

Reputation: Posts: 251Threads: 151Joined: Sep 2014Reputation: 97 #1 These are the features and issues that the council deems necessary to resolve or make decisions on, before the rest of the CodeIgniter 4 planning/roadmap/implementation can proceed. Each of the issues will have a huge impact on the architecture/implementation of other features/issues. This thread conveys our thoughts and decisions.



We welcome your comments, but please stay on topic! This thread is about the essential features of CI4. If you try to hijack the thread, or post non-relevant items that should be or that are dealt with elsewhere, your posts will be deleted without notice. We may post additional comments in fgeature/issue specific threads.



PHP version : PHP 5.5, or the lowest officially supported PHP version at the time of planned release. Impact: plan on 5.5 language features , but not 5.6+

Community input: 23% for 5.4; 13% for 5.5; 50% for 5.6



Using more PHP "standards" : yes. We plan to take advantage of new language features, such as namespaces, traits, generators, etc.

Community input: overwhelmingly in favor.



Composer : We are in favour of more composer integration, but not to the point where CI4 *has* to be installed via composer.

Community input: 50% in favor, but many looking for backwards compatibility



Module support : with namespaces, and composer support/integration, we expect most of the "module" issues to fade away.

Community input: overwhelmingly in favor.



Hooks/events : as a replacement/enhancement for the existing kinda hooks mechanism ... makes sense, details to be worked out during implementation.

Community input: 87% in favor of this idea.



GIT repo organization : We favor a separate repo for CI4, but a single one, incorporating the framework files and the user guide. It will be sufficiently different from CI3 that this makes sense. It would be cool if CI4 could be deployed from the repo download *or* from composer, per developer preferences.

Community input: no poll setup. Comments: all over the map.



"Borrowing code" from other frameworks : maybe, big maybe, if such other components can be integrated without pulling in loads of dependencies & expectations. Not clear that this would be super helpful or not.

Community input: no poll setup. Comments: all over the map.



Micro framework : No. CI has always been "full-stack". We expect that developers may wish to make their own "distribution", to this end.

Community input: no poll setup. Comments: all over the map.



Magic routing toggle : we agree - conventional "CI magic" or fully declared routing.

Community input: 80% in favor.



Bundling other packages : big no. No ORM, scaffolding, auth, etc, etc. That is NOT what CI is about. Making it easy to integrate other such packages: +1



Dependency injection : cool idea. Has the possibility of making "plugins" and "modules" easier, as well as eliminating the "CI super object".

Community input: mixed.



Backwards compatibility : makes sense as a way to ease the pain of migration to CI4? Would be awkward in most cases!

Community input: BC garnered only 9% vs ease of use, modern & speed as "vision" considerations.



Driver support : we are in favor of "drivers" as a mechanism to handle developer preferences, eg for "standard" third party stuff. We already have drivers in some places, of course we'll have it in some form where it makes sense. James Parry

Project Lead Find

gadelat





Member

Threads: 3

Joined: Feb 2015

Reputation: Posts: 128Threads: 3Joined: Feb 2015Reputation: 7 #2 Can you clarify why is planned separate github repository for CI4? I don't see any advantages, but merging of fixes/features between CI3<->CI4 will be harder as opposed to just new branch Find

sv3tli0





PHP Dev

Threads: 24

Joined: Oct 2014

Reputation: Posts: 421Threads: 24Joined: Oct 2014Reputation: 18 #3 (05-05-2015, 02:30 AM) gadelat Wrote: Can you clarify why is planned separate github repository for CI4? I don't see any advantages, but merging of fixes/features between CI3<->CI4 will be harder as opposed to just new branch

At the moment we have (lets name them components), 3 major components at the current repo.



1. Framework (System) - which is the CodeIgniter itself.

2. Startup App (Application) - which is the startup application based on CI Framework.

3. User Guide - which is only documentation about the framework.



1 repo should matches 1 component not 3 at once.



The current repo can stay but it should be repo for end usage. Not for any development. Instead each component should have repo for itself and at the end they can be merged into 1 official repo for client usage.



I know many people can say .. "This is pointless lets leave all things at 1 place"..



Yes but No.. We shouldn't think just which will be easier for us. There should be logic inside the framework development. And separation of its Documentation , Framework Core and Startup App should be made. At the moment we have (lets name them components), 3 major components at the current repo.1. Framework (System) - which is the CodeIgniter itself.2. Startup App (Application) - which is the startup application based on CI Framework.3. User Guide - which is only documentation about the framework.1 repo should matches 1 component not 3 at once.The current repo can stay but it should be repo for end usage. Not for any development. Instead each component should have repo for itself and at the end they can be merged into 1 official repo for client usage.I know many people can say .. "This is pointless lets leave all things at 1 place"..Yes but No.. We shouldn't think just which will be easier for us. There should be logic inside the framework development. And separation of its Documentation , Framework Core and Startup App should be made. Digital Ocean Best VPS Hosting : Find

Narf





Me

Threads: 1

Joined: Oct 2014

Reputation: Posts: 1,591Threads: 1Joined: Oct 2014Reputation: 121 #4 (05-05-2015, 04:10 AM) sv3tli0 Wrote: (05-05-2015, 02:30 AM) gadelat Wrote: Can you clarify why is planned separate github repository for CI4? I don't see any advantages, but merging of fixes/features between CI3<->CI4 will be harder as opposed to just new branch

At the moment we have (lets name them components), 3 major components at the current repo.



1. Framework (System) - which is the CodeIgniter itself.

2. Startup App (Application) - which is the startup application based on CI Framework.

3. User Guide - which is only documentation about the framework.



1 repo should matches 1 component not 3 at once.



The current repo can stay but it should be repo for end usage. Not for any development. Instead each component should have repo for itself and at the end they can be merged into 1 official repo for client usage.



I know many people can say .. "This is pointless lets leave all things at 1 place"..



Yes but No.. We shouldn't think just which will be easier for us. There should be logic inside the framework development. And separation of its Documentation , Framework Core and Startup App should be made.

None of this is true. None of this is true. Find

sv3tli0





PHP Dev

Threads: 24

Joined: Oct 2014

Reputation: Posts: 421Threads: 24Joined: Oct 2014Reputation: 18 #5 (05-05-2015, 04:26 AM) Narf Wrote: None of this is true

And what is it then? And what is it then? Digital Ocean Best VPS Hosting : Find

Narf





Me

Threads: 1

Joined: Oct 2014

Reputation: Posts: 1,591Threads: 1Joined: Oct 2014Reputation: 121 #6 (05-05-2015, 08:46 AM) sv3tli0 Wrote: (05-05-2015, 04:26 AM) Narf Wrote: None of this is true

And what is it then?

That's already answered by @jlp above ... you just made stuff up without even reading the topic. That's already answered by @jlp above ... you just made stuff up without even reading the topic. Find

orionstar





Member

Threads: 4

Joined: Oct 2014

Reputation: Posts: 124Threads: 4Joined: Oct 2014Reputation: 5 #7



How do you mean that exactly?



The community has a strong opinion about it, we need that function built into the core and we don't want to solve the problem with a third party addon or our own... Personally I don't want "packages" like in Laravel or "Bundles" like in Symfony, I want Modules, these are similar solutions but works differently. For Laravel 4 there is a package what is almost what we want (it has CLI generators, but we don't need that), check it out: "Module support: with namespaces, and composer support/integration, we expect most of the "module" issues to fade away"How do you mean that exactly?The community has a strong opinion about it, we need that function built into the core and we don't want to solve the problem with a third party addon or our own... Personally I don't want "packages" like in Laravel or "Bundles" like in Symfony, I want Modules, these are similar solutions but works differently. For Laravel 4 there is a package what is almost what we want (it has CLI generators, but we don't need that), check it out: https://github.com/creolab/laravel-modules and of course take an overview about wiredesignz's solution. I know it's not perfect and some of you have a strong opinion about the guy, but the community is using his addon for years... Website Find

Edwin





Junior Member

Threads: 5

Joined: Apr 2015

Reputation: Posts: 16Threads: 5Joined: Apr 2015Reputation: 0 #8 hi, regarding module support, there is number of question in my mind:-



- will it change a lot of syntax or structure of framework compare with codeignter 3.x?

- compatible with codeignter 3.x for upgrading to codeignter 4? Find

kilishan





CI Project Lead

Threads: 65

Joined: Oct 2014

Reputation: Posts: 1,278Threads: 65Joined: Oct 2014Reputation: 82 #9 (05-05-2015, 01:47 PM) orionstar Wrote: "Module support: with namespaces, and composer support/integration, we expect most of the "module" issues to fade away"



How do you mean that exactly?

While it's too early to say exactly how this would work let's imagine a scenario where everything was forced to be namespaced. At that point, a "module" could be simply a folder that you keep your namespaced classes in. Any class could be pulled in by new \Namespaced\Class() . This would take care of any models and libraries in a module. Controllers could be routed to via a namespaced class, maybe? The only thing left to provide a solution for is the non-class files, like config files, language files, and helpers. It should be possible for the framework to find those files via the namespace (which it could read from composer.json) and a set folder name, like the traditional CodeIgniter folders, helpers, config, etc.



Again - this is way too early to say this is how it will work, but is one possibility depending on the final architecture. While it's too early to say exactly how this would work let's imagine a scenario where everything was forced to be namespaced. At that point, a "module" could be simply a folder that you keep your namespaced classes in. Any class could be pulled in by. This would take care of any models and libraries in a module. Controllers could be routed to via a namespaced class, maybe? The only thing left to provide a solution for is the non-class files, like config files, language files, and helpers. It should be possible for the framework to find those files via the namespace (which it could read from composer.json) and a set folder name, like the traditional CodeIgniter folders, helpers, config, etc.Again - this is way too early to say this is how it will work, but is one possibility depending on the final architecture. Support Development • CodeIgniter 4 Foundations • Practical CodeIgniter 3 • Myth:Auth Website Find

John_Betong





Super Moderator

Threads: 40

Joined: Oct 2014

Reputation: Posts: 449Threads: 40Joined: Oct 2014Reputation: 2 #10



http://community.sitepoint.com/t/codeign...y/195723/8 Some interesting points relevant to this post have been raised on an external forum: Built with CI4 Website Find