I have a question: was there any particular reason why the order of the static::always_load() and \Router::add(\Config::get('routes')) was changed between 1.8.1.6 and 1.8.2 in fuel.php on around line 190?
It totally broke my app and now I have to overwrite a core class!
Let me explain: I know that packages are not designed to work that way but still I created a basic app package with a basic cms-like toolset, basically a mini-app, completely with its own modules and routes, which is where the trouble begins. I did this so it can be reused for other projects and update across all projects so that I can keep the app code itself separated and modular... i'm no native english speaker so its a bit complicated to explain the whole concept :P
it worked very well up to the 1.8.1.6 version but when those two lines switched it could not find the routes in my package anymore :(
I switched it back as a temporary solution because I had too much more important stuff to do. I also tried to load the routes in the bootstrap of the package, which kind of works, but the _root_ somehow doesn't work there but, strange enough, the _404_ does...
I know I totally pushed the concept of Fuel out of proportion (but it was possible), but still I wonder why this change happened and if it could be reverted?
Wow, thanks for the quick reply at this late hour ;)
Well, I kinda did extend the framework with my package :D
Honestly, I knew I went off the trail with my concept :P
But I understand now why it was changed ;) I was searching GitHub this afternoon but could not find this entry ;)
Bummer, I need to rewrite the whole thing...
Followup questions: 1. Can I just "copy", at least most of it since it basically follows he app structure just inside a package, my package stuff into a module so that I have kind of a base module where all the other modules build upon or should I do this in the main app (and add a bunch of gitignores)? 2. Can I overwrite/extend core classes from a module with its own bootstrap or should I rather put this in the app's global bootstrap?
Sorry if I bother you too much, but I just don't want to spend another 5 years on a new concept just to find out again that I was totally stupid and do the same thing over again...
There are a few fundamental differences between modules and packages. Packages have a bootstrap, which is meant for framework integration work when you load the package (for example class overloads, loading new classes into the autoloader, etc). Modules do not, they are app extensions, and contain controllers, views, routes, etc.
2. No, You overload core classes either in the app bootstrap itself (which is what we do, as they are usually app specific), or in a package bootstrap (the only other bootstrap you have).
Having said that, I know people who have extended the Module class, and copied the "load the bootstrap" logic from Package::load to Module::load, to provide bootstraps to modules too...
p.s. Given the investment and amount of work, I would probably go for overloading the init() method of \Fuel\Core\Fuel in the app bootstrap, and revert that commit.
since my package was almos an exact copy of the app structure, including its own modules (yes, you read that right, and it worked :D), I finally decided to properly move it to the app folder ;) I worked on that the past couple of days. I ran into some minor problems when porting the package's modules to the normal classes/controller folder but everything looks and works good so far. Still need to load the models in the bootstrap since they don't follow the required class pattern, but I'll rename them later since this works at the moment.
Maybe I'll release it to the public one day ;)
I think overloading of Fuel\Core\Fuel would just have been another possible future breakpoint. I was thinking about that too for a moment but dropped it very quickly.
I just hope that Fuel 2 will not not require a major rewrite.
But thanks again ;) As I said, I was a total newbie when I started 4-5 years ago.
If and when there is a Fuel 2, it will most likely not be backwards compatibile.
Which is not an issue, Fuel 1 will be maintained for the forseable future, if only because all our apps use it to, and rewriting them to another framework simply isn't commercially viable.
Donate
