Application/ThirdParty folder necessity

[iamkirkbater]

Hi. I just came across this repo today after the latest PHPWeekly came out, and I started browsing through the codebase. I noticed you have an Application/ThirdParty folder.

Wouldn't composer be a better resource to store third party libraries in? I think it would be better to try to sway the community as a whole to start using Composer, promoting greater code modularity and reuse.

Not sure if this has been brought up before, so please just ignore if this has been addressed already.

[lonnieezell]

I completely missed that the project was mentioned in PHPWeekly. Thanks for pointing that out!

Thanks for you comment and for taking the time to drop us a line. I really appreciate it!

Here's the interesting dilemma with CI: It has worked with Composer just fine for years, though no outside the core user base ever seemed to mention that. It still does, it just doesn't use it for it's core autoloading for a few different reasons I won't get into here. When we polled the community before starting this re-write one of the big things that came out was that a large portion still wanted the "download the zip, get started" functionality to work.

Combine that with concerns about it's use on locked-down shared hosting, and the fact that repository sizes can get pretty large, which is a concern for some countries where internet is very limited and expensive, as well as hosting, and additionally with a large portion of users being new users that resist the command line, and we've found ourselves walking a fine line. Personally, I'm a huge fan of Composer, and love what it's done for the community as a whole. I initially pushed for using it as the core, but after more discussions happened, and some more of these facts came out, and I found myself convinced it wasn't right for this particular project. But, we still work seamlessly with it, just by setting a single config setting, which handles loading it's autoloader also.

These same arguments make it difficult to include some great third-party packages as part of the core, unfortunately. So the few that we do have (basically just Zend Escaper and Kint) are updated through Composer locally, and then automatically copied over to third-party folder so they can be easily zipped up for distribution.

[iamkirkbater]

Gotcha. That all makes sense, then. I may not agree with it, but I can understand the reasoning behind it.

I come from Laravel-land, but a lot of the newer features that they're spending time building and adding don't work for what I do at my job. My Co-worker has been using CI for many years now, and I really like the direction that CI is headed with this release, as it seems to be the very happy medium between what I am used to and what my co-worker is used to, and we have already started thinking about the future of what we're doing with CI4.

Some of the things that I would like to see is 1) The ability to drop in an ORM of sorts in place of the current DB implementation, something like Eloquent or Doctrine, but of course keep the current implementation bundled and enabled by default; and 2) The ability to use a full-fledged templating language, something like Twig, by default instead of plain PHP files for views.

I'd love to help work on these features if they're wanted (as I don't like just demanding things from open source projects), but I figured I'd bring it up for discussion before spending time working on them and really diving in if they're not wanted.

[lonnieezell]

No worries at all. Both of those things are planned, and they shouldn't take much work, I believe.

ORM: We should be able to drop in either or Eloquent or Doctrine through Composer currently and use it. There are some things that could be done to make the integration a little smoother, I'm sure, especially as far as the Model class goes with auto-loading the database instance. Perhaps just adding an $autoloadDB setting to the model would be enough so it wouldn't create duplicate connections if they weren't needed. Then, any user could add their own entry to the Services class. Would love to hear other ideas about integration there, also, as it's definitely something that we've talked about.

TEMPLATES: This should be doable by implementing the RendererInterface and modifying the Services class to pass the correct class back, but verifying how well that works and documenting it would be a good thing. It's definitely on our to-do list, we just haven't made it there yet. :)

So, yes, we'd love the help in these areas. We've said from the start we weren't going to include them in the framework, but wanted to make it simple for others to use them if they wanted.

EDIT: And I can appreciate everyone's Laravel experiences. I have been using it in the day job for the past few months. It has definitely solidify both things I like and dislike about frameworks. :)

[iamkirkbater]

Awesome. Is there any kind of mailing list or roadmap or something I can join/look at?

[jim-parry]

Clarifications...

1. To me, "dropping an ORM in" means making it easy for developers to add a dependency, and integrate their usage of such a package. It does not imply that such a package would ever find its way into CI or its distribution. There are simply too many of them, each right for different developers for different reasons. This has been the subject of many, many debates and flamewars.
2. To me, "dropping a template engine in" falls into the same category, almost. Adding anything other than the View\Parser class, which I am in the middle of, runs into the same arguments and flamewars as those for an ORM. The "almost" ... FuelPHP has done an elegant job of building Fuel-compliant adapters for different templating engines - https://github.com/fuel/parser. Such an approach could work, because the template engines would still be external and up to a developer. The key is the common base class (their approach) or interface (our approach).

I believe that a similar accommodation could be made for authentication, along the lines of JAAS from the JaveEE world. That, however, is another huge debate and flamewar.

I think there could be a good case for some sort of service locator, which would return an appropriate renderer based on known criteria, such as the extension of a view file. I am working lots on my course hub web site, which runs some content through a markdown renderer (to make HTML) and then the CI parser (to do substitutions) - a single view provided by the Services class doesn't work for that.

The roadmaps are all on our forum, though sometimes a bit hard to follow because of all the noise.
The issues section on this repo contains a number of issues flagge "help wanted" - that is basically our current todo list.

Goot to see your interest and observations!

[lonnieezell]

Agreed. And I'm definitely on board with an extension-based system for views like Fuel or even Laravel (IIRC).

[iamkirkbater]

@jim-parry That's exactly what I was thinking. Some kind of way where I can (as a user) set up a configuration file to tell the application which "driver" I want to use. I do not want to be opinionated at all when it comes to the ORM, but have it completely extensible so anyone could "drop in" their own flavor at their whim.

I do think that we should be opinionated about the template engine, though. I don't have any experience with any template engine other than Twig, but I do think that some engine should be used by default with the ability to switch it out as wanted. something something separation of concerns and all, but if this has already been discussed like you said then I will drop it here. Just adding my $0.02.

I'll start looking into some of the open issues, and I'll check out the forums. Thanks for pointing me in the right direction. I look forward to helping!

[iamkirkbater]

Actually, I was just thinking about this again, regarding @lonnieezell's quote in the first reply:

When we polled the community before starting this re-write one of the big things that came out was that a large portion still wanted the "download the zip, get started" functionality to work.

Combine that with concerns about it's use on locked-down shared hosting, and the fact that repository sizes can get pretty large, which is a concern for some countries where internet is very limited and expensive, as well as hosting, and additionally with a large portion of users being new users that resist the command line, and we've found ourselves walking a fine line.

How hard would it be to add a process to the release to just include the vendor directory with any third party libraries in it into the zip folder that's provided in the release? You could even write a composer script to go through and clean pre-release or something, by removing all of the .git folders within the vendor folder. Then, (theoretically) you wouldn't need to do anything more than just unzip and go, provided that your public folder is already being pointed to as the correct destination by the webserver but that's more sysadmin stuff than it is framework-specific.

For those who want to kick and scream and not use composer for whatever reason at that point, they could still create the "ThirdParty" folder if they wanted, or they could create whatever folder structure they wanted.

I'm registered and going through the forum now. Let me know if this is something I should bring up there instead of here, though.

[Portaflex]

Hummm, Mr. Ezell, ¿what about of not being under the "mercy" of Composer to manage autoloading in CI4? I'm confused. Thanks.

[Portaflex]

I like CI the way it is -has being-, and also like vendor folder the way composer manages it.

But I think CI is CI and every thing has its place in it. If you want to extend CI with other dependencies, ¡great!, but it should be a personal decision. By the way, FuelPHP has a big amount of nice things, similar to CI, clever. I already pointed out we could join efforts.

If we are going to end up some place like Laravel, please let me know so I don't waste my time. Best regards.

[Portaflex]

By the way, an application is just an interface between users and the database. IMHO we don't need a "super OOP application" at first but a well designed and functioning database (better Postgres). ¿One just don't like SQL?, well, thats too bad for a programmer. Thanks.

[lonnieezell]

If we are going to end up some place like Laravel, please let me know so I don't waste my time. Best regards.

What do you consider being too much like Laravel? Because it's based around Composer, or because it uses many third-party libraries, or because it's very implicit in everything it does, or something else? Everyone has their different views and visions of what makes one framework preferable to another, but you have to be specific :)

No one is saying things are happening one way or another yet, just an excited new member of the community throwing out ideas, trying to find out where we're coming from, etc.

what about of not being under the "mercy" of Composer to manage autoloading in CI4

What about it? I'm confused. Composer is an excellent autoloader that also happens to manage dependencies. We already use it for Zend Escaper in the development realm. We just have it set up so that CI's autoloader can also find it. And we can do that for any packages that we may or may not bring in. I hope you remember our history so far before getting too nervous - we've said no to almost every idea of a third-party package being brought in, for various reasons. And I won't even say that I agree with all of them personally, and that decision has cost me many, many hours of development time and will continue to do so.

By the way, an application is just an interface between users and the database. IMHO we don't need a "super OOP application" at first but a well designed and functioning database (better Postgres). ¿One just don't like SQL?, well, thats too bad for a programmer. Thanks.

I'm lost here. And while I think that some apps are primarily data interfaces, I wouldn't say that's all that all of them are. I've worked on plenty that, were it not for the unique swaths of logic, would not have been any different than just working with the SQL. And, I am not trying to make this a "super OOP" project. Yes, OOP principles are necessary to make something that is easy for the community to maintain in the long run, and to make it simple for developers to extend and use in ways we never thought of. That's part of what makes a great framework, IMHO. Can you take OOP too far? Absolutely! SOLID principles, while good, have caused things to be taken to drastic extremes that have impact on both performance and the ability to keep a mental model of how the application works as a whole in your mind at any one time. It's a delicate balance, and I've personally fought back on that several times throughout this process so far.

Sorry if I seemed a little touchy there, but I'm tired, and a little worn out today.

[Portaflex]

Yes, too much like Laravel would be all that you point out, just the opposite of what CI has been so far, and very slooooooow. For more specific details I would ask Mr. Potencier his opinion ;-)

Dear Mr. Ezell, it is the near past that you pointed out CI4 won't rely on Composer ability to manage dependencies and autoload, and I agree even though personally I use Composer for my projects. Decisions like those for sure cost time and effort, and earn good fame and respect to you and your team mates.

Object oriented overuse is an endless discussion. I know CI4 dev-team is not "dazzled" by Facades or Injections, that's why I like CI and trust you.

Take a beer, sit back, relax and have a nice week-end.