I have several use cases that manipulate and add to the same data at different points in the process.
Each of these use cases share many of the same models, and actions in the process but would require totally different views and structure.
I was thinking of trying out the tips in this article from 8thLight but this was written in 2007.
http://blog.8thlight.com/jim-suchy/2007/02/20/sharing-a-database-among-multiple-rails-applications.html
According to them, the trick is to
(1) make a new folder with the shared models right above the application.
applications_in_same_business_domain
|-shared_models
|-application1
|-application2
|-...
(2) require this new folder or module in your application via enviorments.rb file
(which I believe the equivalent would be config/application.rb because I don't see enviornments.rb in Rails 3.)
They say some code like this will work (in environments.rb)
$: << File.dirname(__FILE__) + '/your_lib_path'
I tried this and it isn't working (in application.rb)...
config.autoload_paths += %W(../../../mardom_shared_models)
Is this the standard way to do this?
An API sounds like another way to do this...but...I don't know anything about API's here. Self-learning 6-Month Noob here)
Helping me get the above to work if it is possible I guess would be the specific question. Can I do this?
But any comments or articles on other matter would be appreciated.
I would need to modify the Rails generators here starting from this link: http://guides.rubyonrails.org/generators.html
I would rather put all models related stuff into a gem, and install gem locally to vengor/gems directory to simplify navigating in it.
Related
First, I am fairly new to Ruby/RoR and so you'll have to forgive me for any wrong terminology, but hopefully I'll get my point across.
I built an ruby app that I am needing to add an extremely simple UI layer using rails. Read up on a previous post of mine that explains the project thoroughly to give you good an idea of what it does. Specifically take a look at the tree outline that I pasted in so you see the existing file structure for the project.
What I need to know, is how to convert this existing project into a rails app? My experience in building something with rails has always started out with rails new app_name, but never anything like this. Any tips would be appreciated.
I saw your parser script, and it is not a daemon (a program that keeps running indefinitely in the background), right?
If I'm right, then you have several options:
The easiest option
Just build a rails application using rails new app_name, and inside some controller action, make a system call to run your script
class SomeController
def some_action
succeeded = system(:ruby, '/path/to/main.rb', '/path/to/some.txt')
# Do some rendering stuff here based on the result of the system call
end
end
This approach is somehow nasty for me, and it's not performant because each system call reads your ruby script and compiles or interprets it then runs it.
The harder option
Refactor your script so that it's features can be wrapped into a gem.
Then you install that gem, require it in your rails app, and use it.
I saw your original ruby script is almost there, it shouldn't be that hard to make it become a gem.
Rails is just "something" on top of Ruby. Especially, you can use any plain ruby objects inside of Rails, anywhere, and this is nothing unusual (google "PORO").
In your case, I would make a simple Rails app in the way you have mentioned yourself with rails new. Then trivially refactor your existing code until you have a simple, standalone class that does what you need to be done but takes its input/output from simple ruby data structures (i.e., method arguments, return values, no global state, no file operations). Then you can use that class from inside your Rails controller (taking input from a HTML form, rendering output to HTML), and also from inside your script (reading input from a file or STDIN, rendering output to STDOUT).
Where you put that class is up to you. In the MVC paradigm, it is not "C" or "V", and one could argue about whether it's "M". So put it into app/models/ or lib/, whatever you like more.
These were great answers and I'm sure they would have worked perfectly. However, they were a little bit more complex than what I was looking for.
What I ultimately ended up doing was just cd into the directory above where the ruby app was located and then just simply ran rails new app_name. Rails will ask if you'd like to overwrite any files that exist already. From there I just integrated my script into the controller actions and created the views.
As we create more Rails applications, I find myself routinely adjusting the project generated by rails new ... in exactly the same ways: adding rspec, capybara + capybara-webkit support, adjusting config/application.rb to our tastes, including several gems we came to love.
I had a look at suspenders, it's a good starting point, but some of their choices differ from ours. Plus it's flexible in places where we don't really want any choice. In fact we'd rather have a couple project boilerplates sharing some customizations and each adding some unique extra's.
What are the options for streamlining/automating a project "bootstrap"? How could we organize a set of boilerplates and let them evolve as our preferences change (not adding options, but changing which made choices are hardcoded)?
I'm thinking in the direction of scripting what I normally do manually starting from rails new, editing the Gemfile, config/application.rb etc, but may be there is a cleaner (future versions compatible) approach or tool?
I really like using the Rails Composer gem/tool for this.
At the basic level when you run Rails Composer it will ask you a series of questions about what gems/configuration options you'd like your new Rails app to have. Then generates your app for you.
I like the "ask me for what I want" approach because different Rails projects may need different things: Postgres vs MySQL, Bootstrap vs Zurb Foundation, etc. 90% of these are usually the same, but it's the 10% difference that gets me.
At the more advanced level, Rails Composer shows you how to use Rails templates to create your own standard modifications, or you could fork Rails Composer to add the options you want (maybe sending a PR back to the project if it's something useful?)
At the expert level, Rails Composer has "starter apps": just pick one of those and go, choices already made for you. Depending on your needs this might be just the kind of thing you're looking for -- digging into how these "starter" apps are created and making one yourself.
I'm starting research on what I'd need in order to build a user-level plugin system (like Wordpress plugins) for a Rails app, so I'd appreciate some general pointers/advice. By user-level plugin I mean a package a user can extract into a folder and have it show up on an admin interface, allowing them to add some extra configuration and then activate it.
What is the best way to go about doing this? Is there any other opensource project that does this already? What does Rails itself already offer for programmer-level plugins that could be leveraged? Any Rails plugins that could help me with this?
A plugin would have to be able to:
run its own migrations (with this? it's undocumented)
have access to my models (plugins already do)
have entry points for adding content to views (can be done with content_for and yield)
replace entire views or partials (how?)
provide its own admin and user-facing views (how?)
create its own routes (or maybe just announce its presence and let me create the routes for it, to avoid plugins stepping on each other's toes)
Anything else I'm missing?
Also, is there a way to limit which tables/actions the plugin has access to concerning migrations and models, and also limit their access to routes (maybe letting them include, but not remove routes)?
P.S.: I'll try to keep this updated, compiling stuff I figure out and relevant answers so as to have a sort of guide for others.
You might want to check out mephisto, it's a blogging software built with ruby on rails and has add-on plugin support. Not sure if it works how you are thinking of, but might give you some good insights. The source can be found on GitHub.
You should look at deface gem. It allows to customize rails views, adding content via hooks and replacing whole views/partials. Spree is using this gem so you can look also at spree. Beside views they also have other solutions for customizing application so you can find more answers to your questions.
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.
With a Ruby module, you can cluster together a bunch of methods that you might use in one place and then include them into a class so it's as if you had written them in that class.
What kinds of practical uses are there for Ruby modules in a rails app?
I would appreciate if someone could mention an example of where they've actually used a module of their own so I have a sense of what situations I should be thinking about creating them. Thanks.
1) Any time I'm about to duplicate (or substantially duplicate) a piece of code: "oh, i could just cut/paste into this other controller . . . "
2) Any time I write code that is very obviously going to be reused in the future.
3) Code of substantial size that has a specific purpose, where that purpose is fairly distinct from the main purpose of the controller/model. This is somewhat related to (2), but sometimes code won't get reused but a module helps for organization.
You can place them in the /lib directory and they'll be loaded with your Rails project.
For example, you can view this repo of mine of an old project: lib directory of a Rails project
So for example, I have the following module:
google_charts.rb
Module GCharts
class GoogleCharts
def some_method
end
end
end
And anywhere in my Rails app, I can access the methods.
So if I were to access it from a controller, I would simply do:
require 'google_charts'
GCharts::GoogleCharts.some_method
We use modules for functionality that isn't tied to ActiveRecord models and hasn't been abstracted into a plugin or gem.
A recent example from our production code base is a library for integrating with Campaign Monitor for email list management. The core of the system uses our user model, but the actual interaction with the extenrl service is abstracted through a module that lives in /lib.