Forum: Rails Engines development Plugin attributes for config values

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.

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

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      svenfuchs@artweb-design.de
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)