1. ERB is similar to it pre-decessor and hence easier to learn. Compared to JSP etc. ERB is similar, you still see lots of HTML tag with interleaved ruby (or Java). Although verbose, it is closer to how your HTML would finally look like.
2. If your team has a dedicated HTML programmer (Designer as we may call them). These folks are very good at plain HTML and don’t want the trouble of converting files and having all the plumbing around when working. It is not efficient for them.

Despite this, I see Haml as valid alternative for following reasons:

• Its been 2 days since I started using Haml. Obviously, I have yet to higher gain productivity but tools like html2haml help a lot with the transition. I am beginning to see that I am not far behind, in terms of productivity, compared to ERb already.
• Especially if you don’t have a dedicated Designer/HTML programmer on your team, haml gives you another shot at productivity.
• I am not sure if this is a good idea but you can have both on the same project, but it sure does work. In fact, you can even have layouts, partials and your main page in different templating engine. Atleast, it lowers the barrier to get started.
• Haml gets ugly when there is too much html nesting. This is a good thing since it encourages breaking your view into partials and making it modular.
• Haml also promotes better view design by making divs/ids/classes most concise. If you are still using tables a lot, you may find yourself using divs with haml.

Try it out. It’s not that bad.

Enjoy!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Great stuff. Enjoy!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

  export HOSTS=<target.host.name>

  # Install Rails stack
  cap deprec:rails:install_rails_stack

  # Install mysql (if it's running on the same box)
  cap deprec:mysql:install
  cap deprec:mysql:config_gen
  cap deprec:mysql:config

  # Install your Rails app
  cap deploy:setup
  cap deploy
  cap deprec:db:create
  cap deprec:db:migrate
  cap deprec:nginx:restart
  cap deprec:mongrel:restart

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Here are a couple of issues I faced when installing:

• Rails 2.3.2 is just released. So, I wanted to use latest and greatest codebase for my solution. However, it seems that latest Spree (version 0.7.0) requires rails version 2.2.2. I found the line that checks for this and tried to change it to 2.3.2 but it failed at runtime. Fair enough, spree 0.7.0 isn’t tested with 2.3.2 yet. I switched back to 2.2.2. And I had to install rails 2.2.2 (in addition to rails 2.3.2 that I have already upgraded to.
• Once I installed rails 2.2.2, I was able to generate a base project using “spree <project name>”. command. I was able to perform “rake db:boostrap” to fill fake data. And then, “script/server” to see that everything is fine. All is great so far. Now, as any serious project, I wanted to freeze rails, all gems used including spree itself. I tried “rake rails:freeze:edge RELEASE=2.2.2″ which installed rails 2.2.2 in my vendor/rails directory. However, it replaced my config/boot.rb with that a rails 2.2.2 app should have. This broke Spree since Spree modifies this file extensively. I had to regenerate a separate spree project to get a valid boot.rb.  I can only hope that frozen rails 2.2.2 and the boot.rb are compatible now. I can still launch my spree app fine.

Next, I will looking at freezing all gems used. And, then it will be time to hit the googlegroups for how to use/customize spree codebase.

Anybody has any more experience with this?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.