Engines.current small useful patch


I wrote some code that I use to simplify including images. This
function needs to know about engines as it is used within engine
views, and can access images within the engine public repository.

I have made a minor modification to the Engines code.

 # Returns the Engine object for the current engine, i.e. the engine
 # in which the currently executing code lies.
 def current(c = caller)
   current_file = c[0]
   active.find do |engine|

(engine.root)) == 0

This allows me to get the current engine from functions which have
been called

Here is the code that uses it, for completeness.

module ApplicationHelper

DefaultIconCategory = “default”

def icon_path(category, icon, root = ‘’)
File.join(’’, root, ‘images’, category.to_s, icon.to_s + ‘.png’)

def icon_src(category, icon, root = ‘’)
paths = [icon_path(category, icon, root), icon_path
(DefaultIconCategory, icon, root), icon_path(category, icon),
icon_path(DefaultIconCategory, icon)]

 logger.info paths

 return paths.find { |path| File.exist? File.join(RAILS_ROOT,

‘public’, path) }

def icon_tag(icon, options={})
category = options.delete(:category) || controller.controller_name
root = options.delete(‘root’) || ‘’

 if defined? Engines
   engine ||= options.delete(:engine) || Engines.current(caller)

if defined? Engines
root = File.join(Engines.config(:public_dir), engine.name)
unless engine.nil?

 css_class = options.delete(:class) || 'icon'

 return tag('img', {'class' => css_class, 'src' => icon_src

(category, icon, root)})

I hope you can merge this into the main code as this is very useful,
and i am sure it is useful to others too.

Kind regards, Samuel

Hi Samuel,

While I like the ideas behind this, having view helpers which
automatically detect which plugin to load content from could be
problematic. For instance, say you want to override your plugin icon
with one from your application? With your current icon_tag method,
this would not be possible, as I understand it.

In this case, I think a little bit more work by the plugin developer
(to specify their plugin name in view helper calls) pays dividends by
making it simpler to track down where the asset originates from.

  • James

I don’t really think your answer is very well thought out.

The image_tag call is in many places, multiple times per view. Why
make the call engine specific when it can be introspected? Otherwise,
you make your views non-portable between engines and any other location.

If you look at the code you can see it is easily possible to override
icons, but the order is very specific. Multiple directories are
checked for icons.

My solution means that ultimately you end up repeating yourself less
and don’t have to write engine-specific views, which is exactly what
I want.

As long as the code works as expected, it is very simple to track
down which assets are being used. Writing it explicitly in code is
exactly what this function avoids.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs