Update nifty_layout to be compatible with Rails 3.1 directory estructure and SCSS #109

Open
wants to merge 9 commits into
from

Conversation

Projects
None yet
5 participants
@pablox-cl

This pull request has 3 main points:

  1. Rails 3.1 has a slightly different directory structure, being the most relevant the location of the stylesheets, now in app/assets and this fork reflect those changes.
  2. I added the corresponding cucumber scenarios and cleaned up a bit (hope for better).
  3. Now SASS a new syntax (SCSS), so I added an option (--scss) to the nifty:layout generator to made possible to chose between the three (erb + css, haml + sass and haml + scss). Please, be free to change the option for whatever you find it's better.

Regards,

PS.- I don't have too much experience in collaborating in other people projects so spare me if I did something wrong.

@ryanb

This comment has been minimized.

Show comment
Hide comment
@ryanb

ryanb Jul 2, 2011

Owner

This looks really great, thank you! We should probably make this dynamic so it only happens when one is using Rails 3.1 that way it doesn't break Rails 3.0. What do you think?

Owner

ryanb commented Jul 2, 2011

This looks really great, thank you! We should probably make this dynamic so it only happens when one is using Rails 3.1 that way it doesn't break Rails 3.0. What do you think?

@pablox-cl

This comment has been minimized.

Show comment
Hide comment
@pablox-cl

pablox-cl Jul 3, 2011

On 2 July 2011 13:50, ryanb
reply@reply.github.com
wrote:

This looks really great, thank you! We should probably make this dynamic so it only happens when one is using Rails 3.1 that way it doesn't break Rails 3.0. What do you think?

Oh, you're right, I didn't take that in mind =P. I guess the
Rails::VERSION::STRING should be enough to be able to
differentiate between 3.0.x and 3.1.x, right?

If it's okay I'll do it.

On 2 July 2011 13:50, ryanb
reply@reply.github.com
wrote:

This looks really great, thank you! We should probably make this dynamic so it only happens when one is using Rails 3.1 that way it doesn't break Rails 3.0. What do you think?

Oh, you're right, I didn't take that in mind =P. I guess the
Rails::VERSION::STRING should be enough to be able to
differentiate between 3.0.x and 3.1.x, right?

If it's okay I'll do it.

@ryanb

This comment has been minimized.

Show comment
Hide comment
@ryanb

ryanb Jul 4, 2011

Owner

That should work, you can just check if it starts with "3.0". There may be better ways, haven't looked.

Owner

ryanb commented Jul 4, 2011

That should work, you can just check if it starts with "3.0". There may be better ways, haven't looked.

mlitwiniuk and others added some commits Jul 20, 2011

Add the corresponding feature to the change in the directory structure
I tried to keep both versions (3.0.x and 3.1.x) on different gemsets
using rvm, but for some reason I couldn't. They kept going back to the main
gemset and being installed there. So, if Rails >=3.1.0 isn't installed
the nifty_layout_3.1 feature is going to fail.
@pablox-cl

This comment has been minimized.

Show comment
Hide comment
@pablox-cl

pablox-cl Sep 3, 2011

Sorry to keep you waiting :P.

I've added the cucumber feature corresponding to the changes mlitwiniuk added.
I created a new file for it, although it's almost the same. I bet there's a way to have them bot on the same file, but the ways I could come up were too complex and would be against cucumber philosophy (afaik).

Since we're using two rails versions now, I tried that both versions (3.0.x and 3.1.x) would stay on different gemsets using rvm, but for some reason I couldn't. They kept going back to the main gemset and being installed there. So, if Rails >=3.1.0 isn't installed the nifty_layout_3.1 feature is going to fail.

Any suggestion, commentary would be welcome :)

Sorry to keep you waiting :P.

I've added the cucumber feature corresponding to the changes mlitwiniuk added.
I created a new file for it, although it's almost the same. I bet there's a way to have them bot on the same file, but the ways I could come up were too complex and would be against cucumber philosophy (afaik).

Since we're using two rails versions now, I tried that both versions (3.0.x and 3.1.x) would stay on different gemsets using rvm, but for some reason I couldn't. They kept going back to the main gemset and being installed there. So, if Rails >=3.1.0 isn't installed the nifty_layout_3.1 feature is going to fail.

Any suggestion, commentary would be welcome :)

@jatinganhotra

This comment has been minimized.

Show comment
Hide comment
@jatinganhotra

jatinganhotra Jan 17, 2012

@pablox-cl I downloaded your Git repository ,did bundle then rake.
I did so while keeping both versions(3.0.11 and 3.1.0) on different gemsets, but the feature would still fail. There were two cases:

  1. When I set the development_dependency 'rails' to '~>3.0'
    the nifty_layout_3.1.feature fails (line nos 13 and 21).
  2. When I set the development_dependency 'rails' to '~>3.1'
    the nifty_layout.feature fails(line nos. 13 and 21).

@ryanb @pablox-cl How to tackle this?

@pablox-cl I downloaded your Git repository ,did bundle then rake.
I did so while keeping both versions(3.0.11 and 3.1.0) on different gemsets, but the feature would still fail. There were two cases:

  1. When I set the development_dependency 'rails' to '~>3.0'
    the nifty_layout_3.1.feature fails (line nos 13 and 21).
  2. When I set the development_dependency 'rails' to '~>3.1'
    the nifty_layout.feature fails(line nos. 13 and 21).

@ryanb @pablox-cl How to tackle this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment