While looking for a way to add haml as the templating engine to my rails app I came upon two distinct ways to do it.
The first one is to just add 'gem "haml-rails"' to the Gemfile.
The second one is to add this code to config/application.rb:
config.generators do |g|
g.template_engine :haml
end
Is there a reason to prefer one over the other?
I prefer the gem because it adds the generators.
Update: The 'haml-rails' gem provides the generators. You'll still need to set the template_engine to haml if you want haml templates by default.
You add your gems into the Gemfile in order to specify external dependencies.
Without adding haml to your Gemfile, Bundler will not know about it and your Haml templates won't render on machines that do not have haml installed.
Just follow the instructions of the documentation... http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#plugin
Or is there a reason to deviate from the recommended way?
Related
This devise generator saves a mountain of work by making all the views necessary for authentication:
rails g devise:views
Can the views above be generated but with bootstrap styling already included? E.g. perhaps similar to how rails new has the css=bootstrap option.
Note: I realise that styling is necessarily opinionated, however, it wouldn't be a bad thing since it would be a time-saver.
Maybe you can use rails templates.
An example with bootstrap and devise: https://github.com/lewagon/rails-templates
Note: It might be specific to the Le Wagon setup but I believe you can use the same approach to tailor it to your needs.
This gem adds bootstrap views:
https://github.com/kroger/devise-bootstrap5
Just add these two gems to your gemfile and you're basically done.
...
gem "devise-i18n"
gem "devise-bootstrap5"
...
I installed a new gem to my Rails project - 'phrasing' - which has gem dependencies on multiple Haml gems. I need the gem (it is adding some phenomenal functionality to my project), and need the dependencies to be installed, but now when I run rails generate scaffold, all of the view templates are generated in Haml rather than ERB. I need views to continue to be generated in ERB.
I reviewed several previous StackOverflow articles, but most focus on converting TO Haml, and the answers around making sure that ERB is the default generator refer to removing lines from the config files, which are not there in my case (it appears that the gems are controlling the default layout format somehow).
(Note: While I appreciate that there may be several advantages to using Haml, and I might consider using it in a new project, I'd like to keep this one consistent, and it's already 80% finished in ERB.)
Turns out this was as simple as adding the following into class Application in the config/application.rb file:
config.generators do |g|
g.template_engine :erb
end
Still not sure why the manual override was necessary, but it is. This fixes it.
through railscasts, I found http://railscasts.com/episodes/328-twitter-bootstrap-basics that with the
gem 'less-rails' (this is the gem https://github.com/seyhunak/twitter-bootstrap-rails)
I can use
rails g bootstrap:themed scaffold-name -f
which applies bootstap to various classes like table, buttons etc. This is amazing timesaver but I am not able to find this for SASS as I am using SASS for my rails app (I am using this gem https://github.com/thomas-mcdonald/bootstrap-sass)
IS there any way to apply bootstap to existing scaffold code as me doing this manually can take lot of time ? OR is there any easy way to put the classes in the .erb files ?
Thanks
I am making the switch to Haml for our rails 3.1 application, and I wonder what is bringing to the table by the 'haml-rails' gem against 'haml' alone, apart rails generators?
It says that it preloads the haml in rails process. Does it means a lot of benefits in performance? We are mixing erb and haml so it doesn't seems to be so good to preload every time the haml library.
Thanks!
I use haml-rails primarily to make the generators output haml views instead of erb. Beyond that, I'm not aware of any difference.
I have features I would like to be portable between my own Rails applications.
I wonder if I should create a gem or a plugin for each feature I want to be portable (sharable).
They are just for Rails (for now) because they include css, html, js and image files.
But I have been wondering, the things provided with plugins could be provided with gems too but not the opposite? So maybe it's better to learn how to create gems, because then you I don't have to learn how to create both gems and plugins? And gems seem to be more popular these days.
But then, from what I can understand one gem is shared between all rails app in the OS. So that means I can not customize it for each Rails app right? In that case, maybe creating a plugin is better cause it should be allowed to customize (editing css, js etc) each feature and to have it stored inside the Rails app itself and not in the OS level.
Some advices would be appreciated!
UPDATE:
So gem works great with css, html, js and image files? In a plugin I think you can have a MVC, your own models, views and controllers. Quoted from Rails guides "Storing models, views, controllers, helpers and even other plugins in your plugins". Is this possible too in a gem? Eg. I want to add a extension that gives me a nice Shopping cart (with own migrations, mvc, asset files) that will be hooked into the current Rails app. Is this possible as gem or only as plugin?
You're right that gems offer a little more than plugins. Versioning and dependencies on other gems being the main ones for me.
One gem needn't be shared across everything using ruby. You can install multiple versions of a single gem and specify in your environment.rb that a gem requires a specific version. E.g.
config.gem 'my-gem', :version => '1.2.3'
Also you can freeze gems into your rails application so that you know you are working with a specific version.
You might want to look at the jeweler gem which makes creating your own gems easier.
UPDATE
To include CSS, javascript etc I think you'll need to make an Rails engine which can then be bundled as a plugin or a gem. I've not done this but there's some coverage here and here.
The push with Rails 3 seems to be towards gems and away from plugins as a lot of support has been added to make gems work as well or better than plugins ever did. A well constructed gem is a great thing to have and share between different applications, and also reduces the amount of testing you will have to do since you can test the gem thoroughly before integration.
For extensions to Rails that use CSS, HTML and other assets, it might be that you need to build an engine to bundle this all up and allow it to fit neatly into an application.
As of Rails 4, plugins will no longer be supported.
Gems are the way forward.