I see in the docs that a package shouldn't be approached through normal HMVC requests, but does that mean a package shouldn't contain its own models? I want to make a bunch of classes available, however separate from my primary application. If I do this through a model, I don't have the ability to load the classes outside of their own HMVC, but if I'm doing it from a package, then I feel like I'm not following standard?
Are migrations going to also be available for packages (like modules, come v1.1 or whatever) if models can be used in them?
shouldn't -> can't.
Packages can't contain URI reachable controllers. A model, like any other piece of code in Fuel, is just a class.
On the other hand, packages are positioned as extensions of the core, which makes them unlikely candidates to have models. Models are about interaction with data, and as such, application and context specific. Which means they are more at home in a module.
You can call a module class the same way as any other class, this has nothing to do with HMVC (which is about requests):
It seems to me that developing a module may better suit your needs.
The way I think of it is that packages are extensions to Fuel itself, and modules are extensions to the application you are developing. Modules use packages as the application does, but a package should be independent of any specific module. Perhaps a close analogy would be RubyGems if you are familiar with that language?
One negative thing that I'm finding, is that Modules don't have a bootstrap file, so there's no way to Autoloader::add_classes() to the Module before hand, which adds unnecessary application load time.
Please define "extra loading time"?
All the bootstrap does is define the location of a class, because for packages it can not be determined automatically by the name of the class.
For app and module classes, that is not the case. There is a direct mapping between namespace/classname and the physical file on disk, which is loaded directly. The "extra time" here is limited to a few lines of code that transforms the namespace and classname to a filename...
For classes in app (including modules), there are no "possible" locations. There is only one possible location, directly determined by the class name.
A class called "Class_In_Parts" lives in app/classes/class/in/parts.php. And in no other location. Nothing is checked or scanned, this class name is converted to lower case, underscore replaced by DS, .php extension added, and loaded.
For modules, APPROOT is replaced by the module directory as prefix of the file loaded.
In case of a package, Fuel can't determine if you want to load a package class or a module class, both are namespaced. So to prevent the automatic filename determination mechanism for kicking in, you can manually add the classname->filename mapping to the autoloader, which skips the determination process if the class name is present in the mapping list.
Donate
