Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

added 2 strategies for extending engine models

  • Loading branch information...
commit 890b9dd4439986e306ec4fc0067a00effa606204 1 parent c12024b
@westonplatter westonplatter authored
Showing with 78 additions and 1 deletion.
  1. +78 −1 guides/source/engines.textile
View
79 guides/source/engines.textile
@@ -657,6 +657,84 @@ h3. Improving engine functionality
This section looks at overriding or adding functionality to the views, controllers and models provided by an engine.
+h4. Overriding Models
+
+Engine Models can be extended by (1) implementing decorators, or (2) including modules.
+
+h5. Decorators
+
+Decorators extends Engine's model classes in the main application by open classing Engine models at run time execution.
+
+<ruby>
+# MyApp/app/decorators/models/blorgh/post_decorator.rb
+
+Blorgh::Post.class_eval do
+ def time_since_created
+ Time.current - created_at
+ end
+end
+</ruby>
+
+h5. Modules
+
+The other strategy is to create modules within the Engine holding all the models' code and include these in the respective Engine's model classes. Thus the Engine's model classes contain a mere include line referencing the respective module.
+
+Engine models can be overriden in the main application by creating a file with the Engine's same namespace and including the module originally referenced in the Engine's model class. ["**ActiveSupport::Concern**":http://edgeapi.rubyonrails.org/classes/ActiveSupport/Concern.html] helps manage the correct ordering of module dependencies at run time (it's worth it to reach the linked documentation).
+
+<ruby>
@radar Collaborator
radar added a note

Why are you overriding Blorgh's original post model? That seems like a Bad Idea(tm).

You would be re-defining the class here and therefore completely disregarding any methods that may be in the engine's class.

What I would recommend doing is going with the decorator pattern continuously, and showing that you can just use a decorator or separate the logic out into sensible components (modules) and include them using a decorator. I'd prefer the module approach because when want to know where the method is located, it will declare that it's from that module:

module Bar
  def a
    puts "a"
  end
end

class Foo
  include Bar
end

p Foo.new.method(:a)

Outputs: #<Method: Foo(Bar)#a> indicating that the method "a" is provided by the module Bar which is included into the class Foo.

So yeah, I think decorators with some modules would be the best way to go here.

@westonplatter Collaborator

I think it is important to give the developer the ability to redefine methods. Why? I've worked with Spree a bit, and we've overriden controllers and models to implement client required logic. For example,

module Bar
  def a
    puts "a"
  end
end

class Foo
  include Bar
  def a
    "a prime"
  end
end

# Foo.new.method(:a)
# => #<Method: Foo#a> 

# f = Foo.new
# f.a
# => a prime

I still think the extended model file should be in the MyApp/app/models folder for initialization purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+# MyApp/app/models/blorgh/post.rb
+# overrides Blorgh's original Post model
+
+class Blorgh::Post < ActiveRecord::Base
+ include Blorgh::Concerns::Models::Post
+
+ def time_since_created
+ Time.current - created_at
+ end
+end
+
+
+# Blorgh/app/models/post.rb
+# this class is overriden by the MyApp Post model
+
+class Post < ActiveRecord::Base
+ include Blorgh::Concerns::Models::Post
+end
+
+
+# Blorgh/app/concerns/models/post
+
+module Blorg::Concerns::Models::Post
+ extend ActiveSupport::Concern
+
+ # 'included do' causes the code within to be evaluated in the conext
+ # where it is included, rather be executed in the module's context.
+ included do
+ attr_accessor :author_name
+ belongs_to :author, :class_name => "User"
+
+ before_save :set_author
+
+ private
+
+ def set_author
+ self.author = User.find_or_create_by_name(author_name)
+ end
+ end
+
+ # methods defined here will be instance methods by default
+ def some_method
+ 'some method string'
+ end
+
+ module ClassMethods
+ def some_class_method
+ 'some class method string'
+ end
+ end
+end
+</ruby>
+
h4. Overriding views
When Rails looks for a view to render, it will first look in the +app/views+ directory of the application. If it cannot find the view there, then it will check in the +app/views+ directories of all engines which have this directory.
@@ -772,7 +850,6 @@ s.add_dependency "moo"
To specify a dependency that should only be installed as a development
dependency of the application, specify it like this:
-<ruby>
s.add_development_dependency "moo"
</ruby>
@radar

Why are you overriding Blorgh's original post model? That seems like a Bad Idea(tm).

You would be re-defining the class here and therefore completely disregarding any methods that may be in the engine's class.

What I would recommend doing is going with the decorator pattern continuously, and showing that you can just use a decorator or separate the logic out into sensible components (modules) and include them using a decorator. I'd prefer the module approach because when want to know where the method is located, it will declare that it's from that module:

module Bar
  def a
    puts "a"
  end
end

class Foo
  include Bar
end

p Foo.new.method(:a)

Outputs: #<Method: Foo(Bar)#a> indicating that the method "a" is provided by the module Bar which is included into the class Foo.

So yeah, I think decorators with some modules would be the best way to go here.

@westonplatter

I think it is important to give the developer the ability to redefine methods. Why? I've worked with Spree a bit, and we've overriden controllers and models to implement client required logic. For example,

module Bar
  def a
    puts "a"
  end
end

class Foo
  include Bar
  def a
    "a prime"
  end
end

# Foo.new.method(:a)
# => #<Method: Foo#a> 

# f = Foo.new
# f.a
# => a prime

I still think the extended model file should be in the MyApp/app/models folder for initialization purposes.

Please sign in to comment.
Something went wrong with that request. Please try again.