Modular Rails info

Wrong diff?

Yes, indeed :-(

For a simple example see

http://github.com/mschuerig/branch_db/blob/master/rails/properties.rb

where I use it in a plugin to show the currently active database as one of the properties. (This is useful as the plugin switches databases according to git branch.)

Just

@@@ruby property name, value

or







@@@ruby
property name { ... }

That's all there is to it, really. I'm careful not to litter the global environment, the properties files are instance_eval'ed each in a fresh (almost) BlankSlate object.

More properties could be read from files in, say, lib/info/properties. But I haven't implemented that yet.

If it is sensibly possible across deployment alternatives, I'd like to add a bit more of instrumentation, e.g. for changing parameters or clearing caches.

Looks good to me, but ideally this example style documentation would
be built-in to rails so plugin authors have somewhere to look.

Oh, sorry, of course there is documentation missing. I didn't bother to adapt the tests, either. I only intended the patch as a proof of concept. Firstly, to see if and how well it works, second, to have a something concrete to talk about the idea.

I'll add the obligatory details then, as soon as I get too it.

Ah, I may have the wrong impression about what you were trying to achieve. I was thinking about just display information about a plugin, but on closer inspection it seems like you actually care about augmenting some set of application-specific information instead. Apologies for that.

From a plugin perspective, I wonder if it might be simpler to provide plugins with an API, rather than a DSL, for manipulating this information? For example, in init.rb, they could do something like

Rails.properties["Active Connection"] = ActiveRecord::Base.configurations[RAILS_ENV]['database']

# or
Rails.property "Active Connection", ActiveRecord::Base.configurations[RAILS_ENV]['database']

# or
Rails.property "Active Connection" do
  ActiveRecord::Base.configurations[RAILS_ENV]['database']
end

# etc...

This seems slightly more elegant and code-ish to me than providing a DSL and another file for plugins to deal with.

James, as you noticed yourself, displaying static information was not my primary aim, although I see no reason why the information available from plugin#about (about.yml) should not be displayed.

I was not trying to introduce a DSL, either. The property method was already there in the original code and that I'm using #instance_eval is only for the purpose of keeping the namespace clean.

Regarding the API, I'm not opposed to it in general. For the single callback, I don't care whether it is Rails#property or #property.

What I'd like to have is a mechanism that is simple to use and not tied to plugins. If an application programmer sees fit to expose a property, it should be easily possible, and it should happen in a well-defined place, e.g. lib/info/properties/xzy.rb.

The latter is important, I think, to impose order on the architecture. As with configuration and initialization, there are (ought to be) things that can only be affected in specific places. If you want to find out about them, you know where to look.

These properties files are intended as an interface definition. They are not meant to implement anything, only expose properties that are implemented elsewhere.

Does that make sense?

I've attached a somewhat cleaned up version of the patch. It adds the feature that properties files at lib/info/properties/*.rb are loaded.

The controller tests pass, the other unit tests still fail. I'm not sure if it's worthwhile to make them pass as I don't want to support the interface they're using anyway.

I'd like to hear suggestions about what the interface should be.

I'm still using Rails.configuration.loaded_plugins, instead of moving it to Rails.plugins. Right now, the usage as is, is more consistent with, e.g. Rails.configuration.middleware.