Welcome Guest, Not a member yet? Register   Sign In
Poll: Incorporate Composer?
You do not have permission to vote in this poll.
yes
46.67%
28 46.67%
no
36.67%
22 36.67%
maybe
16.67%
10 16.67%
Total 60 vote(s) 100%
* You voted for this item. [Show Results]

[split] Composer?
#11

plus one - no dependencies, simple install, fast as possible performance "out of the box".

or put another way -- don't spend time bringing in other peoples tools -- focus on improving the framework.
Reply
#12

Everyone brought up good points here. It seemed to have gotten away from me that one of the most basic features of Codeigniter is that you can unzip a package and have it working. After having deployed things via git for so long, command line with composer is 2nd nature. It's easy enough to add your own composer dependencies.
Reply
#13

(This post was last modified: 04-09-2015, 12:24 AM by GeorgeD.)

(04-08-2015, 06:09 AM)dmyers Wrote: I think the core should be 100% included (which BTW I currently download via composer). As for some of the other Libraries and Helpers. I think the team should deprecate the ones that just add "busy work" to the project and the team (calendar, cart, ftp, javascript, etc...). Anyone that needs them can download a zip file with the "last supported versions" and drop them in as needed. Having the team continue to support a FTP or calendar library seems like wasted of their limited time.

I agree with this libraries, but I don't think we should erase most libraries. I think we should not transform CodeIgniter into Laravel, nor in a microframework, CodeIgniter should be between this extreme.
You and all the people that think only the core matter should go with a microframework. Why you don't use Slim framework(it has composer as you like, and doesn't have many libraries) or other microframework?
Reply
#14

(04-09-2015, 12:23 AM)GeorgeD Wrote:
(04-08-2015, 06:09 AM)dmyers Wrote: I think the core should be 100% included (which BTW I currently download via composer). As for some of the other Libraries and Helpers. I think the team should deprecate the ones that just add "busy work" to the project and the team (calendar, cart, ftp, javascript, etc...). Anyone that needs them can download a zip file with the "last supported versions" and drop them in as needed. Having the team continue to support a FTP or calendar library seems like wasted of their limited time.

I agree with this libraries, but I don't think we should erase most libraries. I think we should not transform CodeIgniter into Laravel, nor in a microframework, CodeIgniter should be between this extreme.
You and all the people that think only the core matter should go with a microframework. Why you don't use Slim framework(it has composer as you like, and doesn't have many libraries) or other microframework?

GeorgeD, I think it becomes a balance of what to support as a team moving forward.


A lot of the libraries and helpers where added by Ellis Labs because they built it for a specific need in there paid product Expression Engine. Therefore they continued to update it as THEY needed (which had it's draw backs but no need to open old wounds)

Moving forward does the current team have the resources (all volunteer) to support the  decisions/code made by the previous owner?

I'll pick on Calendars in this example but you could replace that with any PHP file I have listed below.

There are many other PHP libraries out there which do calendars a lot better than CodeIgniter. Back when Ellis Labs sold CodeIgniter as part of Expression Engine they couldn't use a number of these "better" calendar libraries for various reasons (license, ethics, etc...).

As the current CI team migrates the code base forward they need to spend countless hours updating the Calendar code and documentation. This will also slow release time!

Being this is now a completely volunteer effort, resources are limited. I'm not saying drop everything just the code that only a small percent of people actually use or 9 out of 10 times they just download another library for anyway.

Most of these where Expression Engine Specific.
smiley_helper, xml_helper, Ftp (Don't promote this insecure protocol), Javascript (to specific to EE), Trackback, Xmlrpc, Xmlrpcs, Pagination (to specific better libraries), Calendar (to specific better libraries), Cart.php (better libraries), Table.php (to EE specific).

I am sure a few other "fit the bill" but you get the point.

If it's part of the included code the CI team will need to "support it" If the team isn't going to continue to add new features or improve it then they can deprecated it and eventual move it to a external download as "unmanaged code". When we switch to version 4 I think that would be the best time to remove EE specific/legacy code.

Another good example is Email (I'm NOT saying to remove it) This is a ever changing library as security requirements change. 1/2 of the time CI's doesn't work with my clients email system for various reasons. I don't expect the CI team to support every system I need to deal with. I think a better use of there time would be to make it more like a driver. Include the library they have now as a driver option and allow others to "drop-in" a new driver as needed (like GMail which seems to change weekly!!).

For example I downloaded a CodeIgniter wrapper for phpmailer (which seems to work 90% of the time) big thanks to Ivan Tcholakov on that one! but, I made it composer compatible.

I spoke about Monolog in another thread because a lot of people felt CodeIgniter should do this and that with logging. Well's it's source is 242k and around 80+ files. I sure hope it can do all that (some of the handlers need even more files installed to function IIRC). I don't want to see CodeIgniter turn into something like that "Just to Support more feature in logging". I'll be downloading 32mb zipped and 8000 files soon.

Let's remove some EE specific/legacy code and make what we have even better!

Bring back "sparks" then we can plugin CodeIgniter specific code for what we don't have.

Trust me I've had some rough time with CodeIgniter over the years but, when it's all said and done as a whole it's still a great product.
I only want the best for it.

DMyers
Reply
#15

There's nothing difficult about composer once you get over the new way of thinking what "installation" is. In fact, it's incredibly useful. So much more so than Pear ever was.
Reply
#16

(This post was last modified: 04-11-2015, 02:06 AM by Muzikant.)

I think, PHP framework should helping with common things. E-mail, cart, calendar, CAPTCHA, even FTP are the common things from my point of view. Without it I have only half reason to use PHP framework. Those solutions do not have to be perfect or the best, but I am glad that the CodeIgniter have them. If I will need better or more advanced functionality of an e-mail for example, I can use external solution. But for basic usage this is more than enough. I understand that people works as volunteers and have limited free time. But again, why should I use framework, which is not helping me with basic things? There is Slim Framework doing it that way and I am not using it and probably will not.
Reply
#17

Hi,
using composer (only?!?) with codeigniter wouldn't fit into codeigniters goal to be easy to use.
For me codeigniter is the framework of choise because of it's easy to use and install. Zend or Cake with their massive command line usage is something that isn't that simple and easy to use.

If the download of codeigniter would be still possible WITHOUT using composer, I would switch my vote to yes.
Reply
#18

Composer !== difficult to use. Just because you're unfamiliar, doesn't mean it's something that's not easy to use. It took me about a year to come to grips with the concept of composer and during that time I also thought it was an absolutely ridiculous, complicated and unimportant thing, when I finally did come to grips with it, I couldn't believe how narrow-minded and inflexible I was being. It's such a useful thing, so I say don't write it off, until you seriously try to use it in a practice project.
Reply
#19

I agree with Jamper, no point on making it confusing to install. I particularly don't care for composer since I'm an out of the box person myself. Keep it real clean and simple. If I want to use 3rd party extensions I want to install them myself and the versions, not composer controlled.
Reply
#20

(11-27-2015, 05:19 PM)idealcastle Wrote: I agree with Jamper, no point on making it confusing to install. I particularly don't care for composer since I'm an out of the box person myself. Keep it real clean and simple. If I want to use 3rd party extensions I want to install them myself and the versions, not composer controlled.

Explain, how Composer will stop you to install third-party code manually in whatever version you like.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB