search

bcosca / fatfree

A powerful yet easy-to-use PHP micro-framework designed to help you build dynamic and robust Web applications - fast!
2.66k stars 446 forks source link

Request: Modularize F3 & Make Framework Installable via Composer #184

Closed knudpotente closed 11 years ago

knudpotente commented 11 years ago

F3 is a fantastic and very powerful, concise framework. To help adoption of the framework, I would suggest that F3 be made installable via Composer - and make full use of Composer's autoloader to load all of its classes on demand.

It would be even better if the different 'packages' that make-up the framework - routing, ORM, templating, testing, etc. - were broken down into sub-projects that were PSR-0 compliant, and installable via Composer on their own. That would mean, that if a developer wanted to just drop-in Axon as an ORM layer for a non-F3 project, they would be able to do it, easily.

bcosca commented 11 years ago

Not so fast. Be aware of license compatibilities.

knudpotente commented 11 years ago

Each component package could be licensed under the same licensing scheme F3 uses now. This would ensure that each component would either be used in a GPL-compatible project, or that - as it is today - the developer would have to contact you to ask for an alternative license before including it in their non-GPL project.

ikkez commented 11 years ago

Hm... at least a good idea, but i think as long as F3 does not have any bigger bundled feature packages, this composer thing is not that necessary. Just download the F3 zip. It contains everything you need. installing / deinstalling packages is as easy as copy & deleting the files in the lib folder. If you need Axon, just copy the db.php file into your libs folder and use it... isn't that an easy drop-in?! :grinning:

knudpotente commented 11 years ago

Composer has 2 main functions: to manage dependencies automatically for you, and to provide you with a smart autoloader for your project classes - so that you only ever have to use 1 single 'require' in all your files: the one for the Composer autoloader. I suggest you have a good look through the Composer documentation, as it is quite well written, and makes it very easy to understand how it could be internally useful to a project like F3 - ie., by making it easier to implement dependency injection and inversion of control throughout the project's components and classes, and making the project more modular.

While this already could provide benefits to F3 internally, the main reason why projects are adopting Composer - and PSR standards - is interoperability: the increased ability for others to use (parts of) your project in their customised solutions and frameworks, because of these common standards. This would make it easier for (parts of) F3 to be used in other projects, and vice-versa: for (parts of) other projects to be brought into F3.

Most well-established libraries and frameworks are adopting the PSR standards - and Composer - to some degree, and for good reason: it helps adoption of their projects by others. These include full-stack frameworks like Zend, Symfony, FuelPHP, and Laravel, as well as several function-specific frameworks and libraries, like PHPUnit, Behat, Codeception, Slim, RedBeanPHP, Doctrine, Twig & Smarty - among many others.

Having to download and unzip files, and keep track of versions and dependencies throughout files and classes manually, even if using git, does not seem to be that practical, when compared to Composer - which seems to be the way of the future.

eazuka commented 11 years ago

All the Composer, PSR standards thing and conformity with the rest of the dev world brings and makes things very complex and complicated. F3 is very simple as it is to download and use. No need to get things complicated.

knudpotente commented 11 years ago

Composer would make it easier for us to automatically update F3, to integrate F3 with other projects, and to combine other projects with F3. You'd also get automatic autoloading of classes. This is simpler, not more complicated.

KOTRET commented 11 years ago

this will require F3 to have a more strict versioning, otherwise it will break your app on some updates...

maciakl commented 11 years ago

Yes, this is a good idea. Composer is a great way to deploy dependencies, and it is growing very fast.

Bcosca, can you explain your licensing concerns? There are lots of GPLv3 projects already distributed via Composer. Also they don't host your packages - you can register the package and point it here onto github.

luxlogica commented 11 years ago

Composer really is the way of the future. I also agree that it would probably help F3 gain wider adoption. I'm also puzzled as to what the licensing issue might be, and I hope the developer will consider this request with care.

bcosca commented 11 years ago

Which dependencies? The framework's or your app's dependencies? PECL and PEAR were also purported to be the way of the future. I guess nobody cared well enough either.

F3 already has a PSR-0+ autoloader. What do we need another one for? Integrating other projects into F3 is already being done with ease by some users. Using F3 as a subframework for another framework, good luck. Using F3 plugins in another framework: no, due to license incompatibilities.

maciakl commented 11 years ago

Just a clarification: PECL and PEAR are package managers. They help you install packages globally on the system. Composer is dependency manager - you ship a tiny JSON file with your project and whoever wants to deploy it just runs composer install to download all dependencies.

Let me give you an example. Let's say I create a project that uses Twig and Doctrine. All I have to do is include a 2 lines JSON file in my github repository and tell the user: download, run composer install and you are ready to go.

Now if I decide to also use F3 in my project I have to tell the user:

  1. Download and run composer install
  2. Download F3
  3. Put it in this folder, set it up this way, etc

So it is more about convenience. If all the packages play nice with Composer, everything works.

Oh, well. Good luck anyway.

seydu commented 10 years ago

Hi. What knudpotente and maciakl suggest is a very good idea. I was looking for a lightweight ORM to use in a tool that a hooks in a deployment process. This tools tries to dectect all commands that have been run in the development stage and put them in a database to help developers not forget to run them after the deployment. I was very pleased by the doc of F3 about the ORM. I added it, but to my surprise the classes could not be autoloaded. Making it PRS-0 compliant will probably boost its adoption.