I would have this helper module inside a namespace within the engine, which will allow people to have a similarly named one in the application. In the application's helper, then I would just include the engine's one, the process of which would make those methods available in the application without overriding the engine. After that, it's just a matter of overriding the methods underneath the `include` statement.
I don't claim that this is the canonical way to do it, but it is a clean way. Maybe other people have thoughts as well on this. On Saturday, 18 June 2011 at 7:00 AM, Jonathan Rochkind wrote: > This one is driving me crazy, appreciate it VERY much if someone can > even give me some hints at where to look in Rails source code to > understand/debug what's going on, I'm getting lost trying to look > through it. > > Rails 3.0.8. I have an engine(gem). > > It provides a controller at app/controllers/advanced_controller.rb, > and a corresonding helper at app/helpers/advanced_helper.rb. (And some > views of course). > > So far so good, the controller/helper/views are just automatically > available in the application using the gem, great. > > But I want to let the local application selective over-ride helper > methods from AdvancedHelper in the engine (and ideally be able to call > 'super'). That's a pretty reasonable thing to want to allow, right, a > perfectly reasonable (and I'd think common) design? > > > > > Problem is I can't get it to work. Let's say there's a method > #do_something in the engine's app/helpers/advanced_helper.rb. > > * If the local app provides an app/helpers/advanced_helper.rb, > then it completely replaces the one from the engine, the one from the > engine isn't loaded at all. (So it has none of it's methods, even > though we just wanted to over-ride one of em). Okay, this isn't > actually TOO unexpected. > > * So I provide a helper called, say > local_advanced_helper.rb(LocalAdvancedHelper) in my local app/helpers. > It DOES load. If it implements a #new_method_name, that helper is of > course available in views (including the engine's views, as it > happens). However, if it tries to over-ride the engine's > #do_something ... the local do_something is never called. > > The engine's helper seems to be 'included' in the module providing > helper methods to views earlier in the call chain (later in the > 'include' order) then my local helpers. So there's no way for local > helpers to over-ride helpers from the engine. (The engine could > theoretically call 'super' to call 'up' to the local view helper with > the same name, but of course that makes little sense, that kind of > dependency is probably seldom appropriate). The ones from the engine > are always first in the call chain, before any view helper modules in > local app. > > > > > > Can anyone shed any light on what's going on? Including pointing me to > the relevant parts of Rails code? Or suggesting any way I can get > this kind of design (local app can over-ride view helpers provided by > Engine) to work? Or tell me if this is a bug, or by design, or > neither (just didn't consider use case), or what? > > Any feedback much appreciated. I've been going crazy trying to figure > this out for hours now. Also posted (in slightly different words) at > http://stackoverflow.com/questions/6380064/rails3-engine-helper-over-ride > > Jonathan > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
