currently I am working on a RoR application (2.3.14 with ActiveRecord) (let's call it A).
Now I started another project B (a remote testing app using capybara, looks something like this: https://github.com/searls/remote-capybara-cucumber-example).
But now I need to have access to the model of application B for test data setup (and possibly test assertions). I therefore would like to use the existing model classes (and some additional libraries like factory_girl if necessary).
I certainly don't want to wrap my project B in a Rails app and copy the model classes. So is there a way to organize A so that B can access the model and create/update/destroy entities?
Are there any keywords for further research (I tried several google searches containing rails model as a gem, as a plugin, externalize rails model etc... but nothing useful turned up (mostly the documentation of ActiveRecord)
Rails 2.x does make it very hard to share the model layer between two applications.
If you don't care about maintaining migrations twice, you can put the models into a gem and then require it in your apps.
Another way is to symlink the db and app/models directories from both applications to a shared folder. This works quite well though you have to be careful because rake tasks and generators now affect both applications.
Rails 3.1 ships with an improved implementation of rails engines. Engines allow you to isolate parts of an rails application and package them up as a gem.
You could try using an alias (symbolic link) to the A's app/models directory in the B project.
On Mac/Linux:
ln -s /volumes/code/project-a/app/models/ /volumes/code/project-b/models
Related
How do I create a gem project nested inside my current Rails project?
I've got a Rails project with several parts that could easily be gems. I would like to extract these parts into gems but not leave the current Rails project. Creating new source control repos for the gems add additional complexity that project or organization is not ready or able to handle. These complexities will be overcome at some point and I would like to be ready.
So far I can only think of these items.
Relocate code to a single directory root. I'm guessing this would be in the vendor path
Create a <something>.gemspec
Link to the gem in the Gemfile of the Rails app
gem 'my_lib_code', path: 'vendor/my_lib_code'
What else do I need to do? I'm sure I'm missing something important.
If this were a c project I would create another shared library that the make process spits out. Or if this where a c# project I would make a .dll. For Java I would...
I'm sure Ruby can do the same as all the other languages. Something that is a half way step between a normally fully extracted gem and just some code siting in my lib path.
This is a perfectly fine approach for a component-based architecture.
You have a single repository, a single test suite, and a single deployment process, while at the same time you are "forced" to think of clean interfaces and separation of concerns.
Of course if you are planning on sharing this functionality with other projects, an externally hosted (but not necessarily public) Gem would serve better.
Implementation wise, you can get some nifty ideas from Stephan Hagemann's talk at this year's RailsConf: "Get started with Component-based Rails applications!"
I want to create another project inside exisiting rails app. My reasoning is that:
They have some common models which I would be able to link to from the inner app,
They operate on the same database
They will have one version control system (no additional configuration and moving required)
Apart from why I want to do that I just want to know why rails prevents you from doing that? As of my testing, no conflicts were exposed.
You should be using Rails Engines for this. Here's a Railscasts episode about it. http://railscasts.com/episodes/149-rails-engines
We've been using rails_admin for a project for a year. It's good, but it would be preferable to have an admin interface that ran in a totally separate process from the main Rails app and from a completely independent code base. rails_admin has so many dependencies that upgrading it along with the main Rails app has proven brittle.
So the functionality we would need is just basic crud for the database tables, with a little bit of magic to make editing associations easier.
Are there any light-weight solutions out there for this? Bonus points for being lightweight & Sinatra-based rather than Rails-based.
I would look into git submodules or subversion externals. The way I've done something similar to this is to
List item migrate the models into a standalone ruby project.
put them in a 'core' subdirectory/module.
Create a new rails project just for administration.
Share the models between the 2 rails apps using an svn external of the 'core' directory into each project's app/models directory.
In other words, does it work similarly to development mode but caches the classes as they are required? Or are all models loaded upfront?
If the latter, how does Rails know to load a model which is a dependency (of another model) before the model which depends on it?
I'd like to know so I can evaluate how feasible it is to load Rails models into a vanilla Ruby project without using the Rails script runner.
The classes are required upfront. Rails basically does require_dependency on everything in config.eager_load_paths, in alphabetic order (see here).
require_dependency is part of Active Support, and is in a nutshell load/require but that integrates with Active Support's dependency tracking. If during this process rails comes across something which is not already loaded (e.g. if A was a subclass of B) then the usual const_missing hooks will fire and load b.rb.
You should be able to setup Active Support like rails does and call the same methods from your non rails project.
I am relatively new to Rails and recently found a couple of useful gems like authlogic that will help in getting the project up and about really fast. However, I have been wondering where to place the model, view, and controller files that are dependent on the plugin, but are core concepts of my project.
For example, is it better to place the User, Role, Session, etc.. models and related controllers with the plugin inside the vendor/ directory, or should I place them inside the root model/, view/, and controllers/ directories respectively?
Even models/views/controllers dependent on plugins should be kept in the app/model, app/view, and app/controllers directories along with your other code.
The "structural" reason is that the bulk of all those files will still be specific to your application. You will probably end up adding fields to the user, or adding has_many statements to your User model, etc. You want all that code with the rest of your core application code in the app directory.
The "functional" reason is that vender/plugins is only for the code specifically relating to that plugin and is treated differently during development. For instance, when you add a new plugin, it is not auto-loaded in development mode. So if your core files were there, they would not be auto reloaded even in development mode.
Anything you write should be in the standard directories. Use vendor for vendor-provided code.
Just as a heads up it is very hard to go wrong watching railscasts on topics you are new to.
Ryan Bates has two covering authlogic and authlogic with OpenID and in anticipation of your next step after authentication- authorization: He has some covering access control as well: Declarative Authorization, and CanCan.