Correct me if I'm wrong, but I don't think both are mutually exclusive.

In fact I think using the decorators strategy to include AS::Concern'ed 
modules seem a pretty good solution: https://gist.github.com/3114185

Also, class_eval blocks with direct definitions inside makes it terrible 
for testing.

On Friday, July 13, 2012 10:55:34 AM UTC-3, Weston Platter wrote:

> Thanks Richard for the examples. From this it seems like you don't monkey 
> patching (Module::Class.class_eval).
>
> Some people like to automatically add methods to ActiveRecord::Base or 
>> other similar classes, this allows them to have a dsl like `acts_as_tree` 
>> but this just pollutes the available methods, and makes me have to remember 
>> unneeded dsl when we ruby already has this type of behavior included with 
>> `include`
>
>
> What's the *benefit* and/or *difference* between 
>
>    - Forem's controller/model Module::Class.class_eval 
> strategy<https://github.com/radar/forem#extending-classes>
>     
>    - Wicked Wizard ActiveSupport::Concern 
> strategy<https://github.com/schneems/wicked/blob/master/lib/wicked/wizard.rb>
>    
>
>
>
> On Friday, July 13, 2012 12:00:16 AM UTC-4, Ryan Bigg wrote:
>>
>>  We're currently discussing the best way to do this on Forem's issue #260 
>> (https://github.com/radar/forem/pull/260). Kunal there wants to add 
>> methods to or modify the Forem::Post class, and so we're going to go with 
>> the app/decorators directory for that.
>>
>>  On Friday, 13 July 2012 at 5:49 AM, Mark McSpadden II wrote:
>>
>> There has been some work done on the edgeguides around this as well. 
>> There are a few notes scattered throughout but I believe this section is 
>> that you are looking for.
>>
>>
>> http://edgeguides.rubyonrails.org/engines.html#using-a-class-provided-by-the-application
>>
>> If that feels incomplete or lacking, please do contribute to make it 
>> better.
>>
>> Mark McSpadden
>>
>> On Thu, Jul 12, 2012 at 3:46 PM, Richard Schneeman wrote:
>>
>> For extending models (and controller methods) I use concerns:
>>
>>
>> https://github.com/schneems/wicked/tree/master/lib/wicked/controller/concerns
>>
>> Then you can include them in other classes or modules in your repo.
>>
>> https://github.com/schneems/wicked/blob/master/lib/wicked/wizard.rb
>>
>>
>> Then you can let your user know to add an `include` statement in the 
>> readme.
>>
>> https://github.com/schneems/wicked
>>
>>   class AfterSignupController < ApplicationController
>>     include Wicked::Wizard
>>
>> Some people like to automatically add methods to ActiveRecord::Base or 
>> other similar classes, this allows them to have a dsl like `acts_as_tree` 
>> but this just pollutes the available methods, and makes me have to remember 
>> unneeded dsl when we ruby already has this type of behavior included with 
>> `include`
>>
>>
>> If you want to add methods directly to the ApplicationController of an 
>> app you can add a application_controller_helper.rb
>>
>> https://github.com/schneems/opro/tree/master/lib/opro/controllers
>>
>> You need to include it 
>>
>> require 'opro/controllers/application_controller_helper'
>>
>> then you can define a helper method for it:
>>
>>   def self.include_helpers(scope)
>>     ActiveSupport.on_load(:action_controller) do
>>       include scope::ApplicationControllerHelper if 
>> defined?(scope::ApplicationControllerHelper)
>>     end
>>   end
>>
>>
>> and finally in your engine:
>>
>>
>>     initializer "opro.include_helpers" do
>>       Opro.include_helpers(Opro::Controllers)
>>     end
>>
>>
>>
>> For extending controllers like devise i've done this:
>>
>> https://github.com/schneems/opro/blob/master/lib/opro/rails/routes.rb
>>
>> You use the user supplied controller or fall back to a default view. 
>>
>>
>> Digging in the devise source as well can be tremendously valuable, though 
>> slightly daunting the first time or two. Let me know if you have some 
>> questions. 
>>
>>
>> -- 
>> Richard Schneeman
>> http://heroku.com
>> @schneems <http://twitter.com/schneems>
>>  
>> On Thursday, July 12, 2012 at 2:12 PM, Weston Platter wrote:
>>
>> Is there a "Rails Way" way for extending models and controllers of rails 
>> engines?
>>
>> The docs have TODO notes with no content for extending controllers and 
>> models (see 5.2 and 5.3 http://guides.rubyonrails.org/engines.html).
>>
>> If there's preferred method, I would love to use it and I'll update the 
>> docs.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/rubyonrails-core/-/q7XpeRAheHkJ.
>> 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.
>>  
>>
>>  -- 
>> 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.
>>
>>
>>  -- 
>> 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.
>>  
>>  
>>  

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/rubyonrails-core/-/X_G0Ly5WeWwJ.
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.

Reply via email to