Class | GemPlugin::Manager |
In: |
lib/gem_plugin.rb
|
Parent: | Object |
gems | [R] | |
plugins | [R] |
While Manager.resource will find arbitrary resources, a special case is when you need to load a set of configuration defaults. GemPlugin normalizes this to be if you have a file "resources/defaults.yaml" then you‘ll be able to load them via Manager.config.
How you use the method is you get the options the user wants set, pass them to Manager.instance.config, and what you get back is a new Hash with the user‘s settings overriding the defaults.
opts = Manager.instance.config "mygem", :age => 12, :max_load => .9
In the above case, if defaults had {:age => 14} then it would be changed to 12.
This loads the .yaml file on the fly every time, so doing it a whole lot is very stupid. If you need to make frequent calls to this, call it once with no options (Manager.instance.config) then use the returned defaults directly from then on.
Resolves the given name (should include /category/name) to find the plugin class and create an instance. You can pass a second hash option that is then given to the Plugin to configure it.
Responsible for going through the list of available gems and loading any plugins requested. It keeps track of what it‘s loaded already and won‘t load them again.
It accepts one parameter which is a hash of gem depends that should include or exclude a gem from being loaded. A gem must depend on gem_plugin to be considered, but then each system has to add it‘s own INCLUDE to make sure that only plugins related to it are loaded.
An example again comes from Mongrel. In order to load all Mongrel plugins:
GemPlugin::Manager.instance.load "mongrel" => GemPlugin::INCLUDE
Which will load all plugins that depend on mongrel AND gem_plugin. Now, one extra thing we do is we delay loading Rails Mongrel plugins until after rails is configured. Do do this the mongrel_rails script has:
GemPlugin::Manager.instance.load "mongrel" => GemPlugin::INCLUDE, "rails" => GemPlugin::EXCLUDE The only thing to remember is that this is saying "include a plugin if it depends on gem_plugin, mongrel, but NOT rails". If a plugin also depends on other stuff then it‘s loaded just fine. Only gem_plugin, mongrel, and rails are ever used to determine if it should be included.
NOTE: Currently RubyGems will run autorequire on gems that get required AND on their dependencies. This really messes with people running edge rails since activerecord or other stuff gets loaded for just touching a gem plugin. To prevent this load requires the full path to the "init.rb" file, which avoids the RubyGems autorequire magic.
Not necessary for you to call directly, but this is how GemPlugin::Base.inherited actually adds a plugin to a category.
GemPlugins can have a ‘resources’ directory which is packaged with them and can hold any data resources the plugin may need. The main problem is that it‘s difficult to figure out where these resources are actually located on the file system. The resource method tries to locate the real path for a given resource path.
Let‘s say you have a ‘resources/stylesheets/default.css’ file in your gem distribution, then finding where this file really is involves:
Manager.instance.resource("mygem", "/stylesheets/default.css")
You either get back the full path to the resource or you get a nil if it doesn‘t exist.
If you request a path for a GemPlugin that hasn‘t been loaded yet then it will throw an PluginNotLoaded exception. The gem may be present on your system in this case, but you just haven‘t loaded it with Manager.instance.load properly.