A couple of discussions later I propose the attached patch for Engines. This super-minimalistic approach allows to do two things: 1. Plugin users can set plugin attribute values in a file [plugin_dir]/ config.yml. If the file is present, it will be parsed and values loaded. If an attribute for a YAML name/value pair hasn't been defined by the plugin dev (see 2.)) it will be defined. # [plugin_dir]/config.yml something: cool 2. Plugin devs can define attributes and default values in init.rb (or elsewhere in the plugin as long as they make sure that the definition is evaluated when the plugin's init.rb is) like this: attr_accessor :something @something = 'default' The mechanism works both when 1.) no config.yml is present and when 2.) no default values have been set by the plugin dev. I think this is a great solution because it's flexible, minimalistic and unobstrusive. Apps like Mephisto can then build further on this mechanism and add another storage layer on top of this. E.g. Mephisto could overwrite Engine::Plugin#load_config_data and access the database to load an AR object holding the config data. Unit tests for this are ready. Please let me know what you think! I'd like to proceed with this stuff as soon as possible so I can start porting/implementing changes for Mephisto.
on 2008-02-02 12:33
on 2008-02-02 12:48
I'm still not sure this kind of functionality is something that should be provided outside of Mephisto - is there really a general need for plugins to have configuration? Additionally, it doesnt seem very natural that application developers should have to create config files within vendor/plugins... Rails' conventions lean towards putting configuration in config/initializers or config/environment.rb, surely? Mephisto has some interesting needs because it needs to provide a general web interface for configuring an unknown set of plugins parameters, and persisting that configuration, but is this something that all rails applications need? I guess it would help me understand the motivation for this feature if I knew what was deficient in Mephisto's current mechanism. Can anyone enlighten me? :) Thanks, James
on 2008-02-02 13:49
Hi James, thanks for the quick response! Am 02.02.2008 um 12:47 schrieb James Adam: > I'm still not sure this kind of functionality is something that should > be provided outside of Mephisto - is there really a general need for > plugins to have configuration? I definitely think so, yes. With framework-level plugins (acts_as_whatever, will_paginate) the Rails developer is the plugin's user, so there's always a place where users can provide their own attributes when they use the plugin in their code (e.g. acts_as_paranoid :with => :deleted, where the option overwrites the default, or will_paginate where one can set a whole bunch of options for the view helper). But with application-level plugins that do not target Rails but an application like Mephisto users often times just install the plugin (unless it's e.g. a Liquid plugin where they "use" the plugin by using additional Liquid drops and filters). So there's no place to provide any customization then. E.g. there's mephisto_full_archives which provides a simple extra archives page that Mephisto doesn't implement itself. One installs the plugin and expects the full_archive page to work. But there's no way to change the "archives" bit of the URL to, e.g., a localized version "archiv". There are lots of similar examples with apps like Mephisto, Beast, Signalwiki, ... This is something that IMO applies to app-level plugins in general, not only for Mephisto. I feel it would be a great move forward to have a more "standard" way of doing it. > Additionally, it doesnt seem very natural that application developers > should have to create config files within vendor/plugins... Rails' > conventions lean towards putting configuration in config/initializers > or config/environment.rb, surely? Actually I've seen plugins often times allowing users customize the plugin from the init.rb file. Again, maybe this is more common for app- level plugins (e.g. plugins that target Mephisto) then it is for framework-level plugins. It's probably the most easy, but also the least reasonable way of doing it because customizations go dodo when one reinstalls the plugin. That said, I forgot to mention that this of course is possible, too: # config/initializers/beta_plugin.rb Engines.plugins['beta_plugin'].instance_eval do @something = 'cool' end It does the same thing the config.yml file does but of course it requires the plugin user (or the plugin install.rb) to create the file manually. Personally I feel both approaches have their merits. With the customization stored in vendor/plugin everything concerning the plugin is in one place (something I feel fits good for app-level plugins). With customization stored in config/whatever all customizations are in one place. > Mephisto has some interesting needs because it needs to provide a > general web interface for configuring an unknown set of plugins > parameters, and persisting that configuration, but is this something > that all rails applications need? I believe it's very useful for app-level plugins that alter full applications. Rails framework-level plugins won't need this in most cases. (Although even will_paginate could benefit from it, so one could customize :prev_label etc. options to default to something else then "« Previous".) > I guess it would help me understand the motivation for this feature if > I knew what was deficient in Mephisto's current mechanism. Can anyone > enlighten me? :) Mostly because it isn't Engines ;) Well, no, of course we *could* just go with an AR storage approach like the one used right now and/or the one you suggested! That's ok ... but it also feels a bit heavyweight. I just feel that this is something that could greatly benefit from being "standarized" further (i.e. having a common way of doing things) for plugins in general. And Engines is a great place to invent and test stuff like this. That said, if I really can't convice you of this being a highly useful invention (I'm convinced that it is) I'd most probably go and talk Rick into going this route with Mephisto. We could then see how this stuff works in Mephisto and pull it one level down to Engines at some point in the future. -- sven fuchs firstname.lastname@example.org artweb design http://www.artweb-design.de grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone) d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)