• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Use Parts From Symfony, Laravel etc

#1
I agree with the use of Namespaces, Traits, Interfaces, etc and PLEASE a proper CLI interaction point, and lets set some plains for a queue system. But more importantly lets look at ways of utilizing some of the amazing stuff the PHP community has developed and use them. Laravel made a smart move using some stuff developed by others to build a solid foundation. If we want to take CodeIgniter to the forefront of the PHP framework collective, we need to step away from making everything on our own and use what the community has available.

The key in my mind to CodeIgniter's future is making it the most adaptable framework. Make it easy to expand on any component the way whether that's drivers or otherwise, but lets use the powerful components like Doctrine, Eloquent, Blade templating, Debug bars, (symfony) Console, and others.

Laravel has always focused itself on an API or REST structure, its even sent its HTML and FORM elements to a community build, rather than having them at the core anymore. This is an opportunity to have CodeIgniter be the full-stack PHP framework of choice for the future. This means modular components to make any project expandable, and modules repeatable, using the latest elements of PHP which also means PHPUnit testable structures. I'm so hopeful that CodeIgniter can be a leading edge framework again. Smile
Reply

#2
CodeIgniter is a name / brand. It shouldn't just star using other framework components.

I agree that there can be made connectors/extension and etc which are based on 3rd party libraries but this should stay out of the ci framework..
Best VPS Hosting : Digital Ocean
Reply

#3
I think one of the nice things about CodeIgniter is the fact you get a complete managed package in a single ZIP file.
I agree there are great PHP packages out there but, I don't think CodeIgniter should become just another symfony package wrapper with a CodeIgniter "flavor".
That said since the team has limited resources and can't design "everything".
I think it should loss a little weight (another thread) and make it so using 3rd party packages (packagist, sparks2, etc...)
if the developer wants is easier.

Don Myers
Reply

#4
(04-14-2015, 11:09 AM)dmyers Wrote: I think one of the nice things about CodeIgniter is the fact you get a complete managed package in a single ZIP file.
I agree there are great PHP packages out there but, I don't think CodeIgniter should become just another symfony package wrapper with a CodeIgniter "flavor".
That said since the team has limited resources and can't design "everything".
I think it should loss a little weight (another thread) and make it so using 3rd party packages (packagist, sparks2, etc...)
if the developer wants is easier.

Don Myers

I agree, you more or less can using composer, so the optimal future of CodeIgniter is to have the system be able to be dropped and have the system elements loaded via composer, this gives developers to freedom to use doctrine, or eloquent inside a codeigniter application, or pull in blade or twig, while also not having to manually stip out parts of codeigniter, or have codeigniter parts that are essentially dead code that is never used in an application. Its mostly an organizational suggestion of having the system directory turned into composer loaded structures, or at least having the option to go with the ZIP or composer based.

Say have composer create-project use a full build with all system parts loaded via composer, then have the ZIP file be a "compiled" version of the stack.
Reply

#5
(04-14-2015, 11:16 AM)mlantz Wrote:
(04-14-2015, 11:09 AM)dmyers Wrote: I think one of the nice things about CodeIgniter is the fact you get a complete managed package in a single ZIP file.
I agree there are great PHP packages out there but, I don't think CodeIgniter should become just another symfony package wrapper with a CodeIgniter "flavor".
That said since the team has limited resources and can't design "everything".
I think it should loss a little weight (another thread) and make it so using 3rd party packages (packagist, sparks2, etc...)
if the developer wants is easier.

Don Myers

I agree, you more or less can using composer, so the optimal future of CodeIgniter is to have the system be able to be dropped and have the system elements loaded via composer, this gives developers to freedom to use doctrine, or eloquent inside a codeigniter application, or pull in blade or twig, while also not having to manually stip out parts of codeigniter, or have codeigniter parts that are essentially dead code that is never used in an application. Its mostly an organizational suggestion of having the system directory turned into composer loaded structures, or at least having the option to go with the ZIP or composer based.

Say have composer create-project use a full build with all system parts loaded via composer, then have the ZIP file be a "compiled" version of the stack.

So are you saying CodeIgniter should continue to create it's own classes but put them on composer? It is already. That's actually how I install it. https://packagist.org/packages/codeigniter/framework. I also use a few other composer packages with a few wrappers. They already know they could make there loader better using newer techniques (another thread). Here is a video I shot for my CI framework which uses composer to install CI and my framework https://www.youtube.com/watch?v=lM6j6Xc0...e=youtu.be

 
or 

Are you saying you think they should just use everyone else's libraries like every other framework and just put a "CodeIgniter" flavor wrapper around it? Because you stated earlier "Laravel made a smart move using some stuff developed by others to build a solid foundation." Can you even install Laravel without composer? Even their new "micro framework" Lumen needs another 10.3mb's of "extras" in the vendor folder.


DMyers
Reply

#6
(04-14-2015, 05:47 PM)dmyers Wrote:
(04-14-2015, 11:16 AM)mlantz Wrote:
(04-14-2015, 11:09 AM)dmyers Wrote: I think one of the nice things about CodeIgniter is the fact you get a complete managed package in a single ZIP file.
I agree there are great PHP packages out there but, I don't think CodeIgniter should become just another symfony package wrapper with a CodeIgniter "flavor".
That said since the team has limited resources and can't design "everything".
I think it should loss a little weight (another thread) and make it so using 3rd party packages (packagist, sparks2, etc...)
if the developer wants is easier.

Don Myers

I agree, you more or less can using composer, so the optimal future of CodeIgniter is to have the system be able to be dropped and have the system elements loaded via composer, this gives developers to freedom to use doctrine, or eloquent inside a codeigniter application, or pull in blade or twig, while also not having to manually stip out parts of codeigniter, or have codeigniter parts that are essentially dead code that is never used in an application. Its mostly an organizational suggestion of having the system directory turned into composer loaded structures, or at least having the option to go with the ZIP or composer based.

Say have composer create-project use a full build with all system parts loaded via composer, then have the ZIP file be a "compiled" version of the stack.

So are you saying CodeIgniter should continue to create it's own classes but put them on composer? It is already. That's actually how I install it. https://packagist.org/packages/codeigniter/framework. I also use a few other composer packages with a few wrappers. They already know they could make there loader better using newer techniques (another thread). Here is a video I shot for my CI framework which uses composer to install CI and my framework https://www.youtube.com/watch?v=lM6j6Xc0...e=youtu.be

 
or 

Are you saying you think they should just use everyone else's libraries like every other framework and just put a "CodeIgniter" flavor wrapper around it? Because you stated earlier "Laravel made a smart move using some stuff developed by others to build a solid foundation." Can you even install Laravel without composer? Even their new "micro framework" Lumen needs another 10.3mb's of "extras" in the vendor folder.


DMyers

Close, Laravel is structured with the application is the shell, where the framework is Illuminate or at least the parts are, the idea here would be to have each component of the system directory be a separate package, this way should one choose to they could run a build of codeigniter via composer which would pull each of these packages in, and the application would run with these packages now loaded

OR

A developer who is not interested in composer methods could simply download a "packaged" version of Codeigniter which would have the latest elements at the time of packaging

This would make updating considerably less cumbersome for active composer using devs, it also enables developers to swap out components of the core framework, say drop the zip library and parser etc, this way devs can even slim down CI if they chose to, and pull in alternatives if they wanted to.

FYI this is just a concept, if we're talking about the future of CI4 it needs to be much more modern, meaning easily unit testable, and more cleanly integrated with dependancy management, even within the framework core, and have a well structured CLI component that can help optimize or expand an application.
Reply

#7
I gotcha so pretty much exactly what Taylor did with CodeIgniter to create Laravel 3. Then later decided using everyone else's core components would be better in Laravel 4 and yet again makes name spacing changes in Laravel 5.

I suppose if every PHP framework followed the PHP PSR's there would really be no advantage to choosing X over Y because, at that point they would all be pretty much the same.

What advantage would there be to use CodeIgniter at that point over Laravel?
Reply

#8
(04-15-2015, 05:39 AM)dmyers Wrote: I gotcha so pretty much exactly what Taylor did with CodeIgniter to create Laravel 3. Then later decided using everyone else's core components would be better in Laravel 4 and yet again makes name spacing changes in Laravel 5.

I suppose if every PHP framework followed the PHP PSR's there would really be no advantage to choosing X over Y because, at that point they would all be pretty much the same.

What advantage would there be to use CodeIgniter at that point over Laravel?

If we are able to make CI faster and simpler than the other frameworks it will have those important advantages.

Its normal that CI has to be updated with the "current" PHP standards which are including different things. 
Using some PSR which is already in use from another framework has nothing to do with those 2 framework advantages ..
Best VPS Hosting : Digital Ocean
Reply

#9
(04-15-2015, 05:58 AM)sv3tli0 Wrote:
(04-15-2015, 05:39 AM)dmyers Wrote: I gotcha so pretty much exactly what Taylor did with CodeIgniter to create Laravel 3. Then later decided using everyone else's core components would be better in Laravel 4 and yet again makes name spacing changes in Laravel 5.

I suppose if every PHP framework followed the PHP PSR's there would really be no advantage to choosing X over Y because, at that point they would all be pretty much the same.

What advantage would there be to use CodeIgniter at that point over Laravel?

If we are able to make CI faster and simpler than the other frameworks it will have those important advantages.

Its normal that CI has to be updated with the "current" PHP standards which are including different things. 
Using some PSR which is already in use from another framework has nothing to do with those 2 framework advantages ..

Ya let's not confuse "updating the framework to current PHP best practices" with "Let's put a CI wrapper on 3rd party packages, maybe build a "few" so we can feel good about ourself."

What I find interesting is that everybody is using the same PSR7 style http-foundation & http-kernel for HTTP Request and HTTP Response which is actually pretty slow compared to other frameworks not using it. Lumen seems to have fixed this (haven't had time to deep dive it yet) even thou they are using the same libraries as frameworks they say they are faster than. Slim says Lumen might change there future road map? hm... Silex of course is Symfony light just like Lumen is Laravel light but all 4 use many of the same "core" packages. Slim already said they where switching to a PSR7 compatible library in version 3 - thou they didn't go as far to say the same Symfony package everyone else is using.

Honestly if CodeIgniter is just following Laravel lock step. I'll just put a Laravel wrapper around my CodeIgniter libraries (like everyone else that left CI) and jump ship to lumen.

DMyers
Reply

#10
(04-15-2015, 07:20 AM)dmyers Wrote: Honestly if CodeIgniter is just following Laravel lock step. I'll just put a Laravel wrapper around my CodeIgniter libraries (like everyone else that left CI) and jump ship to lumen.

DMyers

Almost already ahead of you. I benched Lumen vs Slim 2.0 and I saw a very nice boost. I'm going to be looking to see if I can pull addition stuff from Lumen and get the RPS up. As right now, I'm getting 1800rps from HHVM vs 2600rps from HHVM when its just doing a blank "hello world". So there is 800 rps being used by a stock lumen install.

I have a lot of my own custom libraries. Which actually with Laravel are out of date. By moving over to Lumen, I'm going to be moving to best practices and having better development times. It's crazy, I will even look at replacing a huge and complex app built in CI with Lumen. I'll finally be getting an up-to-date system and lots of functionality im just basically missing.

I personally think Taylor dropped a bomb with Lumen. Such a great strategy. Build on Lumen and if your project grows add to it with packages until you need to upgrade to Laravel. Very smart. Cool
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.