Rails Ruby on Rails → 3.0.2

Comments and changes to this ticket

• 

  Jeremy Kemper May 20th, 2009 @ 09:42 PM

  Wrong diff?

• You flagged this item as spam.
  

  Michael Schuerig May 20th, 2009 @ 10:01 PM

  Yes, indeed :-(

  • modular-rails-info.patch 17.5 KB
• 

  Michael Koziarski May 21st, 2009 @ 03:33 AM

  • Assigned user set to “Jeremy Kemper”

  Perhaps there should be some documentation on how to hook your stuff into this?

• You flagged this item as spam.
  

  Michael Schuerig May 21st, 2009 @ 04:13 AM

  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.

• 

  Michael Koziarski May 21st, 2009 @ 04:29 AM

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

• You flagged this item as spam.
  

  Michael Schuerig May 21st, 2009 @ 09:26 AM

  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.

• You flagged this item as spam.
  

  James Adam May 21st, 2009 @ 03:15 PM

  • Tag changed from “railsinfoproperties, railties, scriptabout” to “plugin, plugins, railsinfoproperties, railties, scriptabout”

  Is there any reason why you didn't use the existing about.yml data for your plugin properties?

  Years ago, when the engines plugin was, well, "more evil" than it is now, we hooked into the Info controller and added details from this file (name, version, etc).

  I'm not hugely invested in any particular approach, but rather than the implementation remains as simple as possible whilst still working.

• You flagged this item as spam.
  

  James Adam May 21st, 2009 @ 03:34 PM

  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.

• You flagged this item as spam.
  

  Michael Schuerig May 21st, 2009 @ 03:54 PM

  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?

• You flagged this item as spam.
  

  Michael Schuerig May 21st, 2009 @ 04:49 PM

  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.

  • modular-rails-info-2.patch 28.9 KB
• 

  Michael Koziarski June 26th, 2009 @ 06:17 AM

  • Assigned user changed from “Jeremy Kemper” to “Yehuda Katz (wycats)”
  • Milestone cleared.

  Yehuda and Carl are currently refactoring the initializer. This should be something we do as part of that work.

  I'm guessing the implementation will be drastically different, but we should have the feature set available.

  Assigning to yehuda so it doesn't get lost.

• 

  Yehuda Katz (wycats) June 26th, 2009 @ 08:25 PM

  • State changed from “new” to “verified”

  Absolutely. This should be added to the work we're doing now.

• 

  Yehuda Katz (wycats) July 2nd, 2009 @ 07:47 PM

  • State changed from “verified” to “hold”

  I accidentally marked this verified ;)

  We'll get this in to the work we're doing now.

• 

  Jeremy Kemper October 15th, 2010 @ 11:01 PM

  • Milestone set to “3.0.2”
  • Importance changed from “” to “”

  [bulk edit]