Created
September 29, 2011 16:40
-
-
Save jrochkind/1251204 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#NOW we do this, in our plugin app/helpers | |
module CatalogHelper | |
def actual_methods | |
'stuff' | |
end | |
end | |
# This is very hard to over-ride in a sensible way in local app. | |
# Instead, if we split things up: | |
module CatalogHelper | |
include CatalogHelperBehavior | |
end | |
# that's IT, all the actual method sare in CatalogHelperBehavior. | |
# No need for ActiveSupport::Concern here, I don't think, | |
# just very straightforward ruby. | |
# NOW... if the local app has no CatalogHelper, no problem, | |
# it'll automatically use the one from the plugin | |
# If the local app DOES have a CatalogHelper, it will completely replace the | |
# one from the plugin. But no problem, as long as you #include.... | |
# in local app: | |
module CatalogHelper | |
include CatalogHelperBehavior # it'll get this from the plugin, great | |
# and now we can individually over-ride whatever methods | |
# from CatalogHelperBehavior we want, and not the others. | |
end | |
# We'd want to stick to a VERY consistent convention here. Like XHelper | |
# always has a module XHelperBehavior with actual implementation, so | |
# when you over-ride locally, you can know you just put XHelperBehavior | |
# in there, and you are forwards compatible. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment