I am on hour 12 of programming, so i might be overlooking something simple, but any suggestions on this issue?
in my app_helper i added a module for a redcarpet filter with haml
module Haml::Filters::Redcarpet
include Haml::Filters::Base
include ActionView::Helpers::TagHelper
def render(text)
options = [:autolink, :smart, :hard_wrap, :no_intraemphasis]
content_tag(:div, Redcarpet.new(text.to_s, *options).to_html.html_safe, :class => "markup" )
end
end
works great in development. but in production, it's throwing
[ !EXCEPTION! ] NoMethodError: undefined method 'content_tag' for Haml::Filters::Redcarpet:Module
why would that be? or what can i check? i even ran the console on production and was able to include TagHelper and use those methods. puzzled...
My guess is that you have different versions of one or more gems on your production box from your dev environment. Do "gem list" in both and add the results to your original post.
The best way to avoid this problem is to use the Ruby Version Manager (RVM) and the 'bundler' gem: you can create a gemset specific to your project and thus ensure that the gems are exactly the same for both versions (prod & dev) of the project.
rvm: https://rvm.io
bundler: http://gembundler.com/
Oh - and if you look down your stack trace you will probably see a reference to the gem that sets up the haml/redcarpet stuff, this is probably the culprit, ie has a different version.
Related
I'm writing an app that will run scripts in a specified folder, and then record the numbers and graph them.
My problem is that if the script is a ruby file, the require statements fail inside the script because bundler seems to have done something funky with the load path.
Running rails runner Datasource.run_jobs fails:
class Datasource < ActiveRecord::Base
def self.run_jobs
require 'aws_sdb'
access_key_id = "REDACTED"
secret_key = "REDACTED" # In all actuality these woudln't be here.
#sdb = AwsSdb::Service.new(:access_key_id => access_key_id, :secret_access_key => secret_key)
Datasource.all.each do |ds|
puts "Updating #{ds.name}..."
unless #sdb.list_domains.include? ds.name
puts "#{ds.name} doesn't exist in SDB, creating a domain for it..."
#sdb.create_domain ds.name
end
#data = "TEST"
data = `#{RAILS_ROOT}/lib/plugins/#{ds.name}`
#sdb.put_attributes(ds.name, Time.now.to_i, data)
puts "Data Collected: #{data.inspect}"
end
end
has_many :graphs
end
(Basing this off your comments on the question)
You will need to add hpricot (and any other gem this needs) to your Gemfile so that they are made available by Bundler. Bundler is by far the easiest way to avoid gem conflicts and tomfoolery.
Imagine this situation: You somehow lose the gems that you have currently. Be this happening through a format or system change or any other reason. Whatever it is, you've lost your gems. How are you going to re-install all your gems? You could keep a list of them somewhere else yourself, but is this truly likely?
Bundler solves this problem by making you state what gems your application requires and only adding those gems to the load path, which is why you can't find hpricot. When you run bundle install the first time, this creates a Gemfile.lock which contains something like this:
GEM
remote: http://rubygems.org/
specs:
abstract (1.0.0)
actionmailer (3.0.0)
...
Because you commit this file to your source control "solution" of choice (be it Git, SVN, FTP, whatever, it's not important) you have a solid way of specifying the precise gems and precise versions of those gems that your application uses.
When/If your gems are wiped, you can simply clone your project again and run bundle install. Because the Gemfile.lock file exists, you'll have exactly the same gems you had originally, even if there were updates.
If you don't want the exact same gems, just run bundle update and this will ignore the specifications in Gemfile.lock and instead revert to depending on Gemfile to define them. This will check for new versions of gems and install them, updating the Gemfile.lock when it's done.
Honestly, I don't understand the Bundler hate. If you could explain in wider terms than "OMG IT SUCKS YEHUDA IS SATAN", I'd be much obliged.
Edit: WedTM asked for a sample Gemfile and related code:
In the Gemfile you'd have this:
group(:scripts) do
gem 'gem1'
end
To require these gems for your scripts:
require 'bundler'
Bundler.require(:scripts)
You may also wish to require the default gems too which you can do by just adding default anywhere to the arguments of require:
Bundler.require(:default, :scripts)
If this for some reason doesn't work I would imagine it would be because it can't locate the Gemfile. This can be fixed by setting the ENV['BUNDLE_GEMFILE'] to the path to the Gemfile.
I wonder if you might be able to use RVM to set up the ruby environment before running your scripts. Maybe something with a gemset like:
data = `rvm gemset use scripts; #{RAILS_ROOT}/lib/plugins/#{ds.name}`
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
When creating a new Rails project using:
rails sample
Then creating a model using:
script/generate model person first_name:string last_name:string
Everything is fine. However, if I add any gems to my environment.rb:
config.gem "authlogic"
And run the same generator, I get the following:
/Library/Ruby/Gems/1.8/gems/rails-2.3.5/lib/rails/gem_dependency.rb:119:Warning:
Gem::Dependency#version_requirements
is deprecated and will be removed on
or after August 2010.
The warning just recently appeared (I think), but I would like to fix it if possible. Any hints or similar experiences?
Thanks.
did you try:
rake gems:install
Btw. If you are using rubygems 1.3.6 then you get this deprecation warning. Previous versions never gave a warning. Also i suggest installing any gem using the command line rather than adding it in the environment.rb file. If the gem(s) you have added in the file is/are not installed, then the generator or any rake task will simply not run. Its a minor bug.
Here is an article that describes a way to prevent the warning:
http://www.mattvsworld.com/blog/2010/03/version_requirements-deprecated-warning-in-rails/
Its no big deal though. Just install gems the normal way and don't add any to your environment.rb file. You'll never get the deprecation warning.
This may be irrelevant as it is rails 3.0 but the answer you are looking for is in this article:
http://omgbloglol.com/post/353978923/the-path-to-rails-3-approaching-the-upgrade
down by the section titled "config.gem is dead, long live bundler", although the article does explain some new things.
You may want to consider upgrading to rails 3.0 and when you do, you will be using the Gemfile inside your application. in here, you will want to include the line:
gem 'authlogic'
and then on the command line, run
sudo bundle install
After that, all should be set :)
Check https://gist.github.com/807008 they suggest to downgrade and upgrade again rubygems.
Worked for me...
Putting these lines in your config/environment.rb between your bootstrap and your initializer will remove the deprecation warning:
if Gem::VERSION >= "1.3.6"
module Rails
class GemDependency
def requirement
super == Gem::Requirement.default ? nil : super
end
end
end
end
I've been fighting left and right with rails 3 and bundler. There are a few gems out there that don't work properly if the rails application hasn't been loaded yet. factory_girl and shoulda are both examples, even on the rails3 branch.
Taking shoulda as an example, when trying to run rake test:units I get the following error:
DEPRECATION WARNING: RAILS_ROOT is deprecated! Use Rails.root instead. (called from autoload_macros at c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:40)
c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in 'join': can't convert #<Class:0x232b7c0> into String (TypeError)
from c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in 'block in autoload_macros'
from c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in 'map'
from c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/autoload_macros.rb:44:in 'autoload_macros'
from c:/code/test_harness/vendor/windows_gems/gems/shoulda-2.10.3/lib/shoulda/rails.rb:17:in '<top (required)>'
Digging a bit deeper into lib/shoulda/rails, I see this:
root = if defined?(Rails.root) && Rails.root
Rails.root
else
RAILS_ROOT
end
# load in the 3rd party macros from vendorized plugins and gems
Shoulda.autoload_macros root, File.join("vendor", "{plugins,gems}", "*")
So...what's happening here is while Rails.root is defined, Rails.root == nil, so RAILS_ROOT is used, and RAILS_ROOT==nil, which is then being passed on to Shoulda.autoload_macros. Obviously the rails app has yet to be initialized. With Rails3 using Bundler now, there's been some hubub over on the Bundler side about being able to specify an order in which the gems are required, but I'm not sure whether or not this would solve the problem at hand.
Ultimately my questions is this: When exactly does the environment.rb file (which actually initializes the application) get pulled in? Is there any harm to bumping up when the app is initialized and have it happen before the Bundler.require line in config/application.rb? I've tried to hack bundler to specify the order myself, and have the rails gem pulled in first, but it doesn't appear to me that requiring the rails gem actually initializes the application.
As this line (in config/application.rb) is being called before the app is initialized, any gem in the bundler Gemfile that requires rails to be initialized is going to tank.
# Auto-require default libraries and those for the current Rails environment.
Bundler.require :default, Rails.env
Well, it was actually fairly easy to trace this down. All the rails libraries are being pulled in in application.rb. The app itself is being initialized in environment.rb.
Rails is suddenly trying to render ERB instead of Haml and I can't figure out why. I've created new rails projects, reinstalled Haml, and reinstalled Rails.
Here's exactly the steps I take when making my application (Rails 2.3.2):
rails> rails test
rails> cd test
rails\test> haml --rails .
rails\test> ruby script\generate model user email:string password:string
rails\test> ruby script\generate controller users index
rails\test> rake db:migrate
Here's what the UsersController looks like:
class UsersController < ApplicationController
def index
#users = User.all
end
end
My routes:
ActionController::Routing::Routes.draw do |map|
map.resources :users
end
I now create views\users\index.html.haml:
%table
%th(style="text-align: left;")
%h1 Users
- for user in #users
%tr
%td= user.email
%td= user.password
Annnd run the server...
I navigate to localhost:3000\users and I get this error message:
Template is missing
Missing template users/index.erb in view path app/views
For some reason Rails is trying to find and render .erb files instead of .haml files.
vendor\plugins\haml\init.rb exists, untouched.
I've reinstalled Haml (Pretty Penny) multiple times and still get the same results.
I've also tried adding config.gem 'haml' to my environment.rb but this also doesn't work.
I can't figure out why suddenly rails will not render haml for me.
Hi it seem like haml is not enabled as Rails plugin ,in order to enable it use the following command .
Go to your application folder from the command prompt type the following
$ cd ..
$ haml --rails <yourproject>
if this doesnot work try installing haml gem with the following code
$ gem install haml
I tried with above example , it did work for me ,i have haml gem installed in my ubuntu system .
Good luck !
NOTE: "haml --rails" was deprecated in HAML 3.1
It's worth noting that the fact that the error message says that it couldn't find index.erb doesn't mean that it didn't look for index.haml too. The erb extension is hard-coded into the error message.
I thought that I had the same problem you describe, but it turned out that my application simply couldn't find my partial at all - it had nothing to do with the file extension.
I had this same problem (see this post) with Rails 2.3.4. Multiple gem uninstall/gem install rails didn't fix the problem. But downgrading to Rails 2.3.2 worked! (I know HAML previously worked in this project with this version of Rails).
sudo gem install -v 2.3.2 rails
Using Rails 3.1, I ran in to the same error and had to restart the web server.
I have this old project in rails 2.3.18, where the gems are managed using bundler, and all I had to do was explicitly use version 3.1.3 It did not work with the latest version (4.0). So in my version I added
gem 'haml', '3.1.3'
did bundle install and restarted my development server :)
Hmmm strange, this might be related.
According to: http://www.ruby-forum.com/topic/101346 you should use resource_url helpers in controllers and resource_path helpers in views. Right?
BUT, if I do use a resource_url helper in a redirect_to call inside my controller, then I get:
Missing template htp://localhost:4000/categories/new.erb in view path app/views
If I use the resource_path helper instead, there aren't any problems at all.
Anyone knows what could be wrong?
Why is the resource_url helper trying to redirect to an .erb file?
This is the error from the server log:
ActionView::MissingTemplate (Missing template http://localhost:4000/categories/new.erb in view path app/views):
haml (2.2.2) lib/haml/helpers/action_view_mods.rb:13:in `render'
app/controllers/categories_controller.rb:15:in `create'
haml (2.2.2) rails/./lib/sass/plugin/rails.rb:19:in `process'
P.S. This is in Rails 2.3.3
maybe your file name is wrong, if you have a whitespace in the end of the index.html.haml_, rails will wrong...
I ran into the same problem and I had to restart my server after installing Haml before my rails app recognized the changes.
I was having this issue with Ruby 1.9x, Rails 2.3.5, and HAML 3.1. I believe part of the issue is that some of the deprecated calls in 1.8 were removed in 1.9.
IMHO, if you want to use HAML in Rails 2, you'd be better off downgrading to Ruby 1.8. (which is what I did to fix my problem). In Rails 2, you MUST have the gem.config "haml" in your config.
Even better, move forward to Rails 3 on Ruby 1.9!
I've had this same problem.
The solution is documented in https://github.com/haml/haml/issues/672
You need to add
config.after_initialize do
require 'haml'
Haml.init_rails(binding)
end
inside your config/environment.rb within the Rails::Initializer.run do |config| configuration block !!
Updated - Not actual anymore:
I name all of my haml file only .haml
To illustrate:
test.haml
# not
test.html.haml
Update 5 years later:
I recommend to name them "file.format.haml", because its much more clear which format is the outcome...