These are the features and issues that are important to CodeIgniter 4, but whose design and implementation need the "essentials" established first. This thread conveys our thoughts and decisions...
We welcome your comments, but please stay on topic! This thread is about the important features of CI4, that depend on the essentials. 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.
URI language identifier in URI: too open-ended right now; there are multiple possibilities, each with pros & cons. Has far-reaching implications.
Community input: 47% in favor.
Our problem: not easily made optional; sorta all-or-nothing; need better/workable implementation strategy
Only segment-based URIs: sounds dated to us, but could be part of magic routing toggle mentioned earlier.
Community input: mixed.
REST support: infrastructure needed; controller base not necessarily.
Community input: 76% in favor
Conclusion: something to work out better during implementation.
Improved error logging: more, yes. Whether PSR-3, debated.
Community input: 70% in favor.
Testing/debugging support: absolutely. phpunit.
Community input: 75% in favor.
AJAX support: ambiguous. This might be better addressed as a plugin of some sort.
Community input: 30% in favor.
Multiple application support: ambiguous wording. Already available, and may just need better tutorial material.
Community input: mixed.
All ok. But you should consider to make it easy to upgrade from 3.0
I guess, It will be a hard upgrade for running systems.
From 2.2 to 3.0 was easy for me. (So easy.) I hope upgrading to CI4 would be.
CodeIgniter new update is really hard to implement on existing websites.Development team should make it easier.
(06-18-2015, 04:54 AM)isabella Wrote: CodeIgniter new update is really hard to implement on existing websites.Development team should make it easier.
I disagree. If you were talking about 3.1 or 3.2 then fair enough. But CI4, if the developers see good reason, should be free from the hassles, time and functionality constraints of upgrade considerations. If CI4 needs to be drastically different for any reason, then so be it. CI3 will still work, and if you want to take advantage of the CI4 benefits, then you do so at the cost of rewriting code. Otherwise you end up in a Microsoft position of supporting so many legacy systems that your new product is devoid of the real benefits it could have offered.
Personally, and I am not just brown nosing here, I have been really impressed with the CI3 release. So much so that I am really looking forward to CI4 and do hope it continues to evolve. In Darwinian terms, CI4 might well be a different species than CI3 so they may not mate easily or at all. If not, hey ho, new sites on CI4, old sites on CI3, whats the problem?
I still have sites built on CI2, as well maintaining older sites running ancient versions of JQuery or Bootstrap. If the client wants to pay for me to upgrade them I do, if not we muddle on. I want CI4 to be free to be the very best it can be without harking back to decisions taken a long time ago just so your upgrade experience is 'easy'.
It might be that CI4 goes in a direction I don't like. Again, so be it. I hope not, but developers put so much time and effort and expertise into development that to constrain them with legacy issues seems almost stupid. I personally learn so much from being dragged into new ideas and methodologies that I find new releases actually exciting and am sure CI4 will do the same. I still remember the awe I felt when CSS stylesheets first came to the fore back in the 90's and that feeling of 'ah, I get it now, wow, that is powerful'. Who would build a site without css now.
Oh, I suddenly feel really old :-(
(06-22-2015, 07:31 PM)PaulD Wrote: But CI4, if the developers see good reason, should be free from the hassles, time and functionality constraints of upgrade considerations. If CI4 needs to be drastically different for any reason, then so be it. CI3 will still work, and if you want to take advantage of the CI4 benefits, then you do so at the cost of rewriting code. Otherwise you end up in a Microsoft position of supporting so many legacy systems that your new product is devoid of the real benefits it could have offered.
Honestly, despite the negatives, I think Microsoft can be used as a positive example in this instance. For example, you can still load a great deal of software in Windows 7/8 which was written for Windows 95/98/ME, even though they have to run in a compatibility layer because Windows 7 is not a direct descendant of those operating systems. Microsoft saw that it would be easier for them to create a series of compatibility layers for the Windows NT line of operating systems to run the majority of the legacy software designed for the Windows 9x and MS-DOS operating systems than to fix the underlying problems in the 9x line itself. The existing software tended to run a little slower and there were some growing pains, but somewhere between the release of Windows 2000 and Windows XP Service Pack 3 the developers had time to update their software to run as native applications.
Similarly, Windows Vista added some flashy GUI features and hardened the security, which exposed some issues with the permissions assumptions made by some applications (including some of MS' own software). Most of the developers eventually fixes these issues, but most of the users associated the issues with Windows Vista itself, so Microsoft re-branded and launched Windows 7, which users accepted as a great success. Windows 10 appears to be a similar effort for Windows 8, but I think the underlying problems with Windows 8 are less likely to have been fixed by 3rd party developers...
MS can go overboard with backwards compatibility, too. For example, with Internet Explorer they've maintained BC with their proprietary JScript/DOM and plugin functionality for so long past its useful lifetime that they've decided to introduce a new browser and keep IE around for backwards compatibility for Windows 10. However, they're sharing a lot of code between the two browsers, so IE could very well be seen as a compatibility layer which just requires a more explicit choice on the part of the user.
Even MS Office uses a compatibility mode to open documents in formats intended for older versions of the software.
In most cases, MS chooses to use a compatibility layer primarily to sandbox applications/documents, knowing that there are security risks associated with their older platforms which they can't tolerate in the newer environments. If all they need to maintain is an API, it's often much less difficult (for them and for users/developers), but APIs often don't stand up well when assumptions about the underlying system have changed.
If they choose to make CI4 in such a way that it is conceptually very different from CI3, it would make sense to use a compatibility layer simply because it might be easier to develop and maintain than it would be to keep the existing API intact. This may have some cost in extra development time, but it usually pays off by giving users a clear upgrade path (and reduces the need to maintain the previous version). After all, if the upgrade path from CI3 to CI4 is any more difficult than it is from CI2 to CI3, many more users would find the maintenance window before end of life on the old version unacceptable (especially if CI4 isn't in development and relatively stable as long as CI3 has been before its release).
I'm a big fan of the compatibility layer idea, actually. It was something that I had been thinking about, unofficially, but you put it very well here.
I don't know how tricky is making a compatible layer for CI3 style code. I wish to have this feature too.
(07-27-2015, 09:36 AM)ivantcholakov Wrote: I don't know how tricky is making a compatible layer for CI3 style code. I wish to have this feature too.
To me, the obvious choice would be to make CI_Controller the compatibility layer and/or tie the compatibility layer to use of the loader ($this->load->xxx()), or add some options to the router to mark all (or specific) routes as backwards compatible routes.
07-28-2015, 01:54 AM
(This post was last modified: 07-28-2015, 01:55 AM by sv3tli0.)
MS is good example but its not correct to compare Windows with CodeIgniter.
Its very different if its made for Clients and if its Developer Tool.
I am against compatibility layers because we don't need them at all.
There is only 1 question which has to be covered BY DEVELOPERS when the new version is Live.
Do you have time for upgrading your CI 3 APP to CI 4?
If there is no time for an upgrade leave it on CI 3..
If there is time for upgrading move it to CI 4..
Why do you need compatibility if you are going to use an OLD app with new Framework ?
Instead of using the power of the new CI version, you will use it to copy the OLD version behaviour..
I don't get it at all ..
07-28-2015, 05:52 AM
(This post was last modified: 07-28-2015, 06:45 AM by ivantcholakov.
Edit Reason: PS
Do you really support something in long term? Let me explain why. You have your own CI3 codebase and a new CI4 framework with the compatibility layer. Then you move your code on top of CI4 and even place it on the productions server. Refactoring to CI4 comes next, you do it gradually, in small finished steps, when you have the time. You make small minor releases and move the corresponding changes to the production server too. In this transitional period the codebase would be a mixture in CI3 and CI4 style. This continues until the new CI4 style is fully adopted.
The point is that your site never stops and it is upgraded in evolutionary manner. No big-bangs, no big-pains.
Something similar I did in the past with sites that were written without a framework at all. I migrated them to CI3 gradually. And this is the working methodology. A big-bang-style attempt for change will be hard, with high risk to fail, especially for relatively complex systems.
In conclusion, I think now that the CI3 compatibility layer is a mandatory development.
PS: There is another aspect I've forgotten to mention. The CI3 third-party libraries - they would need time to be adapted, so it would be nice their CI3 versions to run on CI4 + compatible layer.