Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Designing a package for release with v1 and v2
  • Hey guys, (I guess this one goes out to the core dev team)

    I am rewriting my administrative app as a fuel package (makes more sense in the long run) - you can find it here and now I'm planning to release an alpha version of it (or at least release it as a composer package so I can easily include it in other apps). My questions - of multiple topics - then are:

    1) What's the best layout for this package to be available with v1 and v2? I'm using camelCase and fully namespaced classes in most cases - I haven't updated \Request to allow for camelCased actions, too. Do I rename the folder "classes/" to "src/" and add the package with a psr-1 compatibility in the composer.json? By the way, I'm not an expert on creating composer.json files for providing things, only for using things ;) I looked into the new setup of fuel 1.7.2 and its composer.json setup. But I'm not sure where to put folders config/, lang/, themes/ then. And I'm not sure that a v2-compatible composer.json file looks the same as a v1-compatible composer.json-file

    2) What is your recommendation to dealing with assets bundled with the package? I'm providing the package's own themes and therefore I have a "public/" folder currently at the package's root. I am currently providing a task to publish the package which essentially makes sure that app classes already extending \Fuel\Core-classes afterwards are extending my classes (which in turn are extending \Fuel\Core-classes) but I'm having problems publishing the assets to the designated webroot-path. I'm using the \File-class to copy the directory and I'm experiencing problems mainly because I want to copy the content of "public/" to DOCROOT which is different for the CLI app compared to the actual web-app (instantiated through DOCROOT/public/index.php).

    3) Any other ideas/recommendations you have regarding developing my package in a way that it can be easily migrated to v2?
  • You have to make sure you have your terminology right.

    v2 doesn't have the concept of packages and modules like v1 has. In v2, everything is a loadable class. And a v1 package is not the same as a composer package. And I think you mean something else again when you say "package".

    v2 uses the concept of Component. This is the structure of a component: (at the moment). So you could say that the v1 modules and packages have morphed into components, not that uncommon from the v1 structure.

    A v2 package is a composer package, which is nothing more than a bunch of loadable classes, possibly in a namespace. Which have nothing to do with the application components of a Fuel v2 application.

    You could possibly use a composer package as a replacement of a v1 package (in terms of functionality), as iong as there is nothing application specific in it (like config for example), it only supports class files.

    As to assets, that is always complicated, and most of the solutions are difficult to automate. Solutions I've seen are:
    - symlink the modulename/asset/<type> folder to public/asset/<type>/modulename to make them accessable
    - use a mod_rewrite rule to achieve exactly the same
    - use an asset controller (/asset/get/path/to/your/asset), but make sure security is very tight
    - copy files to /public/asset/... in a module installer

    p.s. nobody is stopping you from changing oil's DOCROOT. The only reason it's different is that is needs to have a value, and there is no way to automatically determine that what is. So it is required that you change it, but nobody does and then complains it's different. ;-)

    And no, the structure of the different v2 application building blocks isn't fixed yet. But using a Component is probably closest to what is now a module.

Howdy, Stranger!

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

In this Discussion