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 [EMAIL PROTECTED] 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) _______________________________________________ Engine-Developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
