Rails - Apr 2010 - Rails (3) Engines and Plugins - How to mix application and vendor code?

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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

sair  do grupo

queria  um nacional

2010/4/24 hornairs
<harry.brundage-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
> .
> 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.