sair do grupo queria um nacional
2010/4/24 hornairs <harry.brund...@gmail.com> > I'm trying to create several large applications that share 60-80 > percent of their functionality. I'd like to find some way to abstract > the common functionality into a gem, plugin, or engine which I can > then deploy as many times as needed for each application. The catch is > each app will definitely need that 20% extra functionality and it may > include changes or enhancements to existing functionality found in the > core. This includes changes to views and layouts, controllers, models, > migrations, tests, etc. I also anticipate that through the development > of these applications bugfixes/new features will be added to the core, > and it'd be great if all the apps built on top of this core could > benefit from them. > > It's been suggested to me to use Engines, but I've encountered a > number of problems. > > First, there doesn't seem to be any way to reopen classes in the > application space as far as I can tell. If you define a model in the > engine's app folder and not in the applications app folder, Rails will > find the engine model and load it and everything will good. If you > define it in both folders, it will find the definition in the > application's app folder and not look anywhere else, so the engine > code never gets loaded. This means I can't reopen my engine's classes > to modify them, which is a really big issue. My solution to this is to > explicitly require the engine space file from inside the application > space file and then subclass the classes defined by the engine in the > application space file. This is far from optimal because a) it sucks > having to require all those files manually, b) the automatic file > reloading across requests seems to be broken, c) the application code > is spread across many locations and I find it harder to navigate and > debug, and d) views can't be "required" and then partially overridden > or anything like that. > > I'm also unsure of how things like tests will play out. I've been > writing all my tests in the application space for now but the tests > that test the core should go into it no? Should I just test overridden > or new functionality in the app space? How can I have my test suite > run the tests from the engine at the same time? > > Migrations are crappy too, how can I manage changes to schema that the > application needs on top of those made by the core? Do I wrangle one > of the file copy solutions and move core migrations into the app > migrations folder? I guess the timestamps would prevent conflicts and > I would just have to ensure the application's migrations which change > the schema to reflect that app's specific needs are run after the core > migrations. > > Any tips or help or suggestions? I'm using Rails 3 and Railtie::Engine > right now, and I'm not that far in so I could still change everything > if need be. I also saw this (http://github.com/pivotal/desert) which > seems to mitigate a lot of these issues but is a little outdated and > far from Rails 3 friendly. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-t...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com<rubyonrails-talk%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
