Hi Andrew, What I'd do is put all of the methods that your plugin's classes use, in modules. So your Element class would look like:
class Element include Core::Element end Your Question class: class Question include Core::Element include Core::Question end etc.., that way, your app would simply do the same, without having to worry about the same file name problem. Does that help? Matt On Tue, Mar 3, 2009 at 10:17 PM, Andrew Roth <[email protected]> wrote: > Here's an example. We have a questionnaire engine, which has models > > RadioField, Selectfield < QuestionWithOptions < Question < Element > Datefield, Textarea, Textfield < Question < Element > > Actually, it's on github. > http://github.com/twinge/questionnaire_engine/tree/2405f96ef12aa7c6eb84ca21370660e7bfbdcaa4/app/models > > I extend that in my application at the Element level to have tags > ('confidential', 'in_summary_view', etc). Ideas how this can be done > without mixins? Require the engines element.rb in my element.rb? > > -Andrew > > > On Tue, Mar 3, 2009 at 10:07 PM, Matt Mitchell <[email protected]>wrote: > >> I *think* he meant that a better solution would be to do it manually, and >> not have the engines automagically mixin stuff for you. For example, instead >> of putting all of your methods right in your app/controllers/controller.rb >> file, put them in a module (lib/controller_methods.rb etc.) then "include" >> and/or "extend" that module in your plugins controller class. >> >> When a parent app uses the plugin, and overrides the >> app/controllers/controller.rb file, simply "include" or "extend" the module >> coming from the plugins' lib/controller_methods.rb file. >> >> That might not be the way James meant, but it's something I did in my own >> apps before I even knew about Engines. It works, and it's very clear as to >> what is happening. >> >> Hope that helps? >> >> Matt >> >> On Tue, Mar 3, 2009 at 9:58 PM, Andrew Roth <[email protected]>wrote: >> >>> Hi all, >>> >>> I was reading James' summary of engines in rails 2.3 ( >>> http://rails-engines.org/news/2009/02/02/engines-in-rails-2-3/) and at >>> the bottom there is >>> >>> "While the code mixing mechanism is quite neat, there are other ways of >>> overriding the implementation of methods which are more typically Rubyish, >>> and involve less magic. I’ll try and post some examples here soon." >>> >>> I'm wondering what those more Rubyish ways are. I rely on mixins in a >>> few of my apps, so I'm eager to learn. >>> >>> thanks, >>> -Andrew Roth >>> >>> _______________________________________________ >>> Engine-Users mailing list >>> [email protected] >>> >>> http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org >>> >>> >> >> _______________________________________________ >> Engine-Users mailing list >> [email protected] >> http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org >> >> > > _______________________________________________ > Engine-Users mailing list > [email protected] > http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org > >
_______________________________________________ Engine-Users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
