Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
How will changes in Package Management in 2.0 effect modules in 1.x projects ?
  • RichardM87RichardM87
    Hi, I stumbled upon a recent blog post written by Phil : http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php One bit which caught my attention was
    By removing the different between modules and packages, making pretty much everything into a package and fully supporting the PSR-0 standard of file and class naming, we become fully package based

    I'm curious to know if I/we will still be able to continue using modules as we do now by creating them in the /app/modules/ folder as we can in 1.x of FuelPHP or would we be expected to move them over to using Composer and/or into packages? Personally I use modules to break up blocks of my applications but these do not form a package in the sense they can simply be dropped into another project (different application to the one the modules are designed to work with). I guess what I'm really asking is how will these plans outlined in phil's blog post (possibly - realise its still a way off) impact how we develop / migrate modules to v2.0 compared with how we do so now? Or would we simply still have support for modules within an application?
    Thanks,
    Richard
  • HarroHarro
    First of all, Packages !== Modules. So don't mix discussions about either of them. There are two blogposts outlining the future of FuelPHP here: http://fuelphp.com/blog/2012/02/the-road-ahead and http://fuelphp.com/blog/2012/03/why-the-20-changes. Those will give you some insight of what's in store for the next major release. You can also follow the work on 2.0 via our development repos at http://github.com/fuelphp. You'll see that 2.0 will support multiple applications in a single install, and applications will support modules. The move to PSR-0 compliancy and composer packages just means that you will be able to install every composer compliant package, even if that hasn't been written specifically for FuelPHP. Which is what Phil was writing about. A lot of packages are generic (or should be) because they are not related to any framework specifically. Think for example about oAuth libraries. Why write a FuelPHP version, a Kohana version, a Cake version, A symphony version and a CI version. Why not write one that can be used unaltered by all of the above? It will not affect 1.x in any way, it will not be introduced until 2.0.
  • RichardM87RichardM87
    Hi, Thanks for the clarification. I totally get why you want to be making these changes and the benefits of the plans. I was just left a little unsure/confused to the reference made to "removing the differences between packages and modules" but based on what your saying this does not sound like it should be a problem. I simply thought while I saw it and I'm at a reasonably good point in development to make a potential change it was worth seeking some confirmation.
    Richard
  • HarroHarro
    The initial plan was indeed to remove the difference (internally), since the technical differences between modules and packages are slim:
    - packages have a bootstrap, modules don't
    - modules are routable, packages not There some other differences, like you can add the package namespace to the core, but you could do that for a module as well if you really wanted to. For 2.0, whether or not something is routable is configurable, so that will eliminate the last point, bringing them closer together. Modules will still be part of the app, while packages will remain outside. 2.0 will support multiple app's, you can even have an app inside a package (which in turn might have modules).
Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Categories

In this Discussion