Using twitter bootstrap rails in an engine - ruby-on-rails

I'm currently trying to develop a rails engine and i would like to use twitter boostrap rails in this engine. I've already added the gem to my dependencies in the gemspec file but there's rails generators that need to be executed to run properly . How could i run the twitter boostrap generators automatically when the engine is installed ?
thanks

In your own generator, you can execute a command line like this :
...
`rails g bootstrap:install`
...
Don't forget the `.
Not sure but you can also try this :
generator = Bootstrap::Generators::InstallGenerator.new
generator.add_assets
generator.add_bootstrap
generator.cleanup_legacy
I think the better way is this :
Rails::Generators.invoke "bootstrap:install", [], :behavior => :invoke, :destination_root => Rails.root

Related

Ruby on Rails: Best way to add gems at project initialization

Every month or so I have to create a Rails project at work.
The procedure is always the same...
Run rails new [...] & edit the Gemfile.
I have about 12 gems I always add on any project no matter what kind of project that is. Most of them are development gems, some of them production gems.
The gems range from ActiveAdmin to BetterErrors and so on. Problem is: I always have to remember which gems I use on a regular basis and run the same procedure everytime I start a project:
Open google.com
Search for the correct names of the gems
Add the gems to the Gemfile accordingly
Repeat til I'm satisfied with my Gemfile
I wish I could do something like this: rails new Project --use-my-gems
I know it's possible somehow using a text-file to store my most used gems (or a Gemfile itself and overwrite the default Gemfile with my).
Basically I want multiple Rails Gemtemplates which can be switched at project initialization by passing an argument to rails.
Use Rails Templates.
You can specify your gems in the template:
gem "bj"
gem "nokogiri"
... with a lot of other options.
Then start your new app with:
rails new app -m ~/template.rb

Strategies for gem tests to ensure the gem works with Rails 3.x and 4.0?

I've seen a few examples of dummy Rails apps (for testing, so they live under test or spec dirs, typically) for use with the Appraisals gem that supposedly work with both Rails 3.x and Rails 4, but they seem hackish and not fully functional. It is somewhat expected, as it is a stripped down Frankenstein monster that is trying to be compatible with various versions of Rails 3 as well as Rails 4.
I've referred to projects that attempt to do this sort of testing (as of late March 2013) like less-rails and ember-rails, but this way to test with various version of Rails doesn't seem very clean, and it is non-trivial to try to debug a non-standard Rails application, especially in a beta version of Rails.
It would be great to have a cleaner way to test that allows you to have a full Rails application for each version of Rails to test with that through some magic is not that difficult to setup or maintain and don't require non-standard path hacks in places, etc.
What are the available strategies for testing gems with various versions of Rails (including at least latest Rails 3.1.x, 3.2.x, and 4.0.0.beta1), and what are the pros and cons of each?
A few options from the related thread on the rails-core list:
Option 1: Appraisal gem and single Rails dummy app
Ken Collins mentioned using appraisal and a Rails "dummy" app:
I test minitest-spec-rails against 3.0, 3.1, 3,2 and 4.0 using a mix
of appraisal and dummy_app that minimally configures itself depending
which rails version it is testing against. Some links:
https://github.com/metaskills/minitest-spec-rails
https://github.com/metaskills/minitest-spec-rails/blob/master/test/dummy_app/init.rb
Similar techniques are used in less-rails, ember-rails, and high_voltage among others.
I used a similar setup to high_voltage in restful_json (v3.3.0) but with a full Rails app created with 4.0.0-beta1 that I modified minimally to also work with Rails 3.1.x/3.2.x.
Update: May want to see permitters for more recent example.
Pros: Fairly simple. Can test against various Rails versions from command-line, etc. Can be very minimal Rails app configuration, or can use full Rails app with minor differences.
Cons: Still reusing same Rails app for multiple Rails versions, so some conditionals and unneeded config. (Possible issues with some files not being applicable in another version of Rails, etc. but does not appear to be a big problem.)
Option 2: Rails version as environment variable with single Gemfile, single Rails dummy app, relying on travis-ci to test in multiple versions
Steve Klabnik mentioned a solution that works with a single Gemfile, a single full Rails app (even though under "dummy" dir, and no use of the appraisal gem, by relying on travis-ci to test:
I've been meaning to discuss this topic more, as I've been doing it
for a bunch of my gems lately. I have two that do this:
Draper: https://github.com/drapergem/draper
LocaleSetter: https://github.com/jcasimir/locale_setter/
Basically, I embed an entire Rails application into the gem, and then
run it against multiple versions of Rails on travis via env vars.
Pros: Simple. No dependency on appraisal gem (not that it is a problem, but may be easier to maintain).
Cons: Still reusing same Rails app for multiple Rails versions from what I can tell. Unless using travis-ci or something that starts with a clean gemset (i.e. if running at command-line), not currently differentiating gemsets so newer gem may be used with older Rails, etc., but Steve said if that were to cause a problem, you could just blow away the lock and re-bundle.
There's a third option : using multiple gemfiles and multiple dummy apps.
Gemfiles
Bundler has an useful option named --gemfile. With it, you can specify what file to use instead of Gemfile, and it will generate a lock file after the same name :
bundle install --gemfile Gemfile.rails3
bundle install --gemfile Gemfile.rails4
This will generate Gemfile.rails3.lock and Gemfile.rails4.lock. So, those Gemfiles can be a copy of your main Gemfile forcing rails version :
source "http://rubygems.org"
gemspec
gem "jquery-rails"
gem "rails", '~>4'
Using gemfiles from dummy apps
Then you have two dummy apps, one for rails-3 and one for rails-4. To use their proper gemfile while running (for example) migrations :
cd test/dummy_rails3
BUNDLE_GEMFILE=../../Gemfile.rails3 bundle exec rake db:migrate
cd ../dummy_rails4
BUNDLE_GEMFILE=../../Gemfile.rails4 bundle exec rake db:migrate
Yeah, that's probably the worst part. But this is mostly a one time setup.
Using gemfiles from rake
To instruct which version to use while running tests, set the environment variable BUNDLE_GEMFILE in Rakefile :
#!/usr/bin/env rake
rails_version = ENV[ 'RAILS_VERSION' ] || '4'
if rails_version == '3'
ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails3'
else
ENV[ 'BUNDLE_GEMFILE' ] = 'Gemfile.rails4'
end
begin
require 'bundler/setup'
rescue LoadError
puts 'You must `gem install bundler` and `bundle install` to run rake tasks'
end
I prefer to ask the user to pass RAILS_VERSION instead of directly BUNDLE_GEMFILE because it's easier to remember and we can just pass "3" or "4".
Using correct dummy app from tests
Finally, in test_helper, switch the dummy app depending on what rails version has been asked for :
# Configure Rails Environment
ENV["RAILS_ENV"] = "test"
dummy_app = ENV[ 'RAILS_VERSION' ] == '3' ? 'dummy_rails3' : 'dummy_rails4'
require File.expand_path("../#{dummy_app}/config/environment.rb", __FILE__)
require "rails/test_help"
From your user perspective
For your user to run tests, he will have to do a one time setup by running the migration tasks with BUNDLE_GEMFILE, which is not that sexy.
But once done, user can run tests against rails-3 and rails-4 without the need to generate the Gemfile each time he wants to switch version, and you can have version specific code and configuration within your test apps without having to put if Rails.version >= '4' statements everywhere.
To run specs :
RAILS_VERSION=3 bundle exec rake test
bundle exec rake test # rails-4 is the default in code I wrote
You can see an example for this method in my activerecord_any_of gem.

How do I mount a mountable application?

I've created a simple mountable application in rails 3.1.3 using command:
$ rails plugin new appToMount --mountable
Than I added some MVC to it. And now I want to mount it to another normal Rails application. The problem is I have no idea how to do this. I tried asking google, but I failed. There are plenty of examples how to create mountable app, but none explaining how to mount it.
You have to add it to the config/routes.rb of your rails app. Something like the following:
mount AppToMount::Engine, :at => '/'
And I recommend you to package your engine as a gem. You can use bundler to create the new gem with the command
bundle new app_to_mount
And finally, you should add the Gem to your gemfile, using the path option. Like in the following:
gem 'app_to_mount', path: '/your/home/app_to_mount'

How to test Rails 3 Engines with Cucumber & Rspec?

I apologize if this question is slightly subjective... I am trying to figure out the best way to test Rails 3 Engines with Cucumber & Rspec. In order to test the engine a rails 3 app is necessary. Here is what I am currently doing:
Add a rails test app to the root of the gem (myengine) by running: rails new /myengine/rails_app
Add Cucumber to /myengine/rails_app/features as you would in a normal Rails app
Require the Rails Engine Gem (using :path=>"/myengine") in /myengine/rails_app/Gemfile
Add spec to the root directory of the gem: /myengine/spec
Include the fixtures in /myengine/spec/fixtures and I add the following to my cuc env.rb:
env.rb:
Fixtures.reset_cache
fixtures_folder = File.join(Rails.root, 'spec', 'fixtures')
fixtures = Dir[File.join(fixtures_folder, '*.yml')].map {|f| File.basename(f, '.yml') }
Fixtures.create_fixtures(fixtures_folder, fixtures)
Do you see any problems with setting it up like this? The tests run fine, but I am a bit hesitant to put the features inside the test rails app. I originally tried putting the features in the root of the gem and I created the test rails app inside features/support, but for some reason my engine would not initialize when I ran the tests, even though I could see the app loading everything else when cuc ran.
If anyone is working with Rails Engines and is using cuc and rspec for testing, I would be interested to hear your setup.
**UPDATE
I changed my setup a bit since I wrote this question. I decided to get rid of the spec directory under the root of the engine. Now I just create a rails app named "test_app" and setup cuc and rspec inside that app like I would normally do in a rails app. Then I include the gem like I did in step #3 above. Since the engine is a sub-app, I guess its just best to test it like it was a normal rails app. I am still interested in hearing if anyone has a different setup.
Rails 3.1 (will) generate a pretty good scaffold for engines. I'd recommend using RVM to create a new gemset called edge and switch to it:
rvm gemset create edge
rvm use #edge
Then install edge rails:
git clone git://github.com/rails/rails.git
cd rails
rake install
From there, you can follow Piotr Sarnacki's mountable app tutorial, replacing calls such as:
bundle exec ./bin/rails plugin new ../blog --edge --mountable
With simply:
rails plugin new blog --mountable --full
The mountable option makes the application mountable, whilst the full option makes it an engine with tests already built-in. To test the engine, this generator generates a folder in test called dummy which contains a small Rails application. You can see how this is loaded in test/test_helper.rb.
Then it's up to you to massage the data to do what it needs to in order to work. I would recommend copying over the cucumber files from a standard rails g cucumber:install into the project and then messing about with it until it works. I've done this once before so I know it's possible, but I cannot find the code right now.
Let me know how you go.
I'll explain how I did it using as example the following gem: https://github.com/skozlov/netzke-core
The testing application. It is in netzke-core/test/rails_app. This app can be run independently, so I can also use it for manual testing or for playing around with new features if I like.
In order for the testing app to load the gem itself, I have the following in application.rb:
$:.unshift File.expand_path('../../../../lib', __FILE__)
require 'netzke-core'
Cucumber features. They are in netzke-core/features. In env.rb I have:
require File.expand_path(File.dirname(__FILE__) + '/../../test/rails_app/config/environment')
... which will load the testing application before executing the features.
Specs. These are in netzke-core/spec. In spec_helper.rb I have the following:
require File.expand_path("../../test/rails_app/config/environment", __FILE__)
... which will load the testing application before running the specs.
Running tests. This setup lets me run the tests from the root of the gem:
cucumber features
and
rspec spec
Factory Girl. Not for this particular gem, but I'm normally using factory_girl instead of fixtures (see, for example, a similar setup in https://github.com/skozlov/netzke-basepack).
A bit late to the party, but here is my strategy:
Generating the rails plugin in 3.2:
rails plugin new blog --mountable --full
This creates test/dummy, containing the dummy rails app
Add the specs to spec
Move the dummy folder to spec (and optionally get rid of the other testfiles)
Adapt specs/spec_helper.rb so it includes
require File.expand_path("../.../config/environment", __FILE__)
instead of
require File.expand_path("../dummy/config/environment", __FILE__)
Execute rails g cucumber:install. It will generate features folder a.o.
Add
ENV["RAILS_ROOT"] ||= File.expand_path(File.dirname(__FILE__) + '/../../spec/dummy')
before
require 'cucumber/rails'
in features/support/env.rb
Now you have features and spec in the root of you project, while the dummy rails app is neatly tucked away under spec/dummy

uninitialized constant on class from ruby gem

I am trying to implement a gem called stanfordparser which can be found here: http://stanfordparser.rubyforge.org/
It is a ruby wrapper for a java natural language parser
I am developing in netbeans using ruby on rails / jruby on a windows 7 machine. My web app works fine otherwise, but when I try to add the parser wrapper it breaks.
Here is the code that is causing a problem:
gem 'stanfordparser'
def show
parser = StanfordParser::LexicalizedParser.new
#words = parser.apply("This is a sentence.")
end
this is in the taskscontroller
and when I go to tasks/show (which, if i remove this code, works fine) I get the following error
uninitialized constant TasksController::StanfordParser
I have made sure the gem is installed in netbeans
I am very new to ruby on rails, and teaching myself, so it may be something obvious
Thanks!
EDIT: I checked my glassfish server logs and it says
SEVERE: Missing these required gems:
stanfordparser
which is weird because I've installed the gem using netbeans, I've done rake gems:install and netbeans says the gem is installed. I've checked in netbeans gems folder and the gem is installed there.
EDIT 2:
So, after a lot of research and head banging, I've decided to simplify things a bit by just trying to use jruby to implement the java classes, now I need to figure out how to import the stanfordparser java classes (there are at least 50), I think I need to compress all the classes into a jar so that jruby can load it. maybe.
If you are using Rails 3 then the gem 'stanfordparser' statement needs to be specified in Bundler's Gemfile within the project's root. Otherwise, for Rails 2.x you need a config.gem 'stanfordparser' statement within config/environment.rb.
I was able to solve my problem the following way:
instead of using the stanfordparser ruby wrapper (which implements java ruby bridge to connect the java stanford parser to pure ruby), I use jruby to just implement the java from the stanford parser.
the code that ended up working:
include Java
require 'C:\\Stanford-Parser\\Current\\stanford-parser.jar'
require 'rubygems'
include_class 'edu.stanford.nlp.parser.lexparser.LexicalizedParser'
lp = LexicalizedParser.new(args) #args is the arguments, not copied here

Resources