Forum: Rails Engines development Engines.current small useful patch

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Samuel W. (Guest)
on 2007-01-19 17:30
(Received via mailing list)

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)] 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),
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
James A. (Guest)
on 2007-09-26 00:30
(Received via mailing list)
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
Samuel W. (Guest)
on 2007-09-26 00:34
(Received via mailing list)
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 topic is locked and can not be replied to.