Hi James,
thanks for the quick response!
Am 02.02.2008 um 12:47 schrieb James A.:
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)
