Rails - May 2011 - Is it okay to use Rails 3.1 for a new project? Is hard to convert over?

I have just started using 3.0.7. I am about 2 weeks of development in.

I was wondering if I should keep building for 3.0.7 or switch to 3.1
before I have too much code to port over? I like most of the new
features (my only fear is not having good error messages when I use
coffeescript), so I''d like to code towards the latest and greatest if
it''s relatively safe.

The javascript standards look interesting, and the attr_accessible fix
sounds like it''s very much appreciated.

Is Rails 3.1 compatible with all the gems out there though?

Also, if I go the 3.1 route, is hard or easy to migrate my project
towards it? How might one go about that?

I guess this is a lot of mini yet related questions. I''d really
appreciate some answers. Thank you.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Well, I got most things to work. I just have to figure out my assets
now. I made the folders and organized them. Now it''s time to get them
to work ;)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

If you see a lot of improvements that you personal would use in 3.1 over
3.0.7, then you should think about switching. Another thing to consider is
deadlines, as upgrading will push the moment you are ready to go to
production further. You yourself raised a great question: will all the gems
work with the new version? If you are using few of them, you should check
that out before making the decision. Some projects use 50+ gems and then an
incompatible gem can bring considerable slowdown to development. Are you
willing to patch the gems/plugins yourself if they aren''t compatible?
My
personal opinion would be continue with development, and upgrade when the
project is on production, because then you''ll be able to focus on 1
task -
upgrading, while if you migrate now, you will have to both keep developing
the functionality, and solve incompatability problems.

2011/5/29 egervari <ken.egervari-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Well, I got most things to work. I just have to figure out my assets
> now. I made the folders and organized them. Now it''s time to get
them
> to work ;)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On May 29, 8:12 am, egervari
<ken.egerv...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Well, I got most things to work. I just have to figure out my assets
> now. I made the folders and organized them. Now it''s time to get
them
> to work ;)
Yay, I got the css to work. I had a circular dependency since I had 2
main stylesheets - one for the public page and for the actual site
when a user is signed in. I will need to namespace the styles with
Scss so that I can confidently merge them together in one, but for
now, I just disabled one of the require statements that includes the
whole tree.

Now to work on the javascripts.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On May 29, 8:28 am, Gintautas Šimkus
<dihita...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> If you see a lot of improvements that you personal would use in 3.1 over
> 3.0.7, then you should think about switching. Another thing to consider is
> deadlines, as upgrading will push the moment you are ready to go to
> production further. You yourself raised a great question: will all the gems
> work with the new version? If you are using few of them, you should check
> that out before making the decision. Some projects use 50+ gems and then an
> incompatible gem can bring considerable slowdown to development. Are you
> willing to patch the gems/plugins yourself if they aren''t
compatible? My
> personal opinion would be continue with development, and upgrade when the
> project is on production, because then you''ll be able to focus on
1 task -
> upgrading, while if you migrate now, you will have to both keep developing
> the functionality, and solve incompatability problems.
All really good points. I am so early in development that upgrading
turned out not to be a problem. Everything basically just worked.
Sure, I had to remove/add configuration in various places... make a
few directories... move some files... etc... but it all just worked.

I think my only big question now concerns the javascript code - where
do I put page-specific javascript? Since it all gets put into 1
javascript file, where do I put my code for the individual pages? Or
do I not worry about it? That seems a bit odd. Do I no longer need
something like require.js?

I''m just a little confused about how to go about this.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Hi again :)

Glad it all worked for you. Even if you didn''t migrate right now, it
would
be a good learning experience (upgrading rails version of production site).
So it''s a win win situation basically. Don''t know the answer
to your JS
problem, maybe somebody else might help on that.

2011/5/29 egervari <ken.egervari-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> On May 29, 8:28 am, Gintautas Šimkus
<dihita...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > If you see a lot of improvements that you personal would use in 3.1
over
> > 3.0.7, then you should think about switching. Another thing to
consider
> is
> > deadlines, as upgrading will push the moment you are ready to go to
> > production further. You yourself raised a great question: will all the
> gems
> > work with the new version? If you are using few of them, you should
check
> > that out before making the decision. Some projects use 50+ gems and
then
> an
> > incompatible gem can bring considerable slowdown to development. Are
you
> > willing to patch the gems/plugins yourself if they aren''t
compatible? My
> > personal opinion would be continue with development, and upgrade when
the
> > project is on production, because then you''ll be able to
focus on 1 task
> -
> > upgrading, while if you migrate now, you will have to both keep
> developing
> > the functionality, and solve incompatability problems.
>
> All really good points. I am so early in development that upgrading
> turned out not to be a problem. Everything basically just worked.
> Sure, I had to remove/add configuration in various places... make a
> few directories... move some files... etc... but it all just worked.
>
> I think my only big question now concerns the javascript code - where
> do I put page-specific javascript? Since it all gets put into 1
> javascript file, where do I put my code for the individual pages? Or
> do I not worry about it? That seems a bit odd. Do I no longer need
> something like require.js?
>
> I''m just a little confused about how to go about this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Depending on the kind of site you might want to use mvc views through
backbone or something similar and launch specific views depending on the
current page, something like so:

html:
body class=´users search_page´
...

and in your coffeescripts (you do use coffeescript :P)

class UserSearchView extends Backbone.View # or controller
   ...
  initialize: ->
    here goes your page specific initializers

$ ->
  window.currentView = new UserSearchView if
$(´body.users.search'').length >
0

I have never been a huge fan of libs like require.js except for real big web
apps, mostly it is better to just dump the whole javascript in one minified
file.


On Sun, May 29, 2011 at 5:41 AM, egervari
<ken.egervari-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On May 29, 8:28 am, Gintautas Šimkus
<dihita...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > If you see a lot of improvements that you personal would use in 3.1
over
> > 3.0.7, then you should think about switching. Another thing to
consider
> is
> > deadlines, as upgrading will push the moment you are ready to go to
> > production further. You yourself raised a great question: will all the
> gems
> > work with the new version? If you are using few of them, you should
check
> > that out before making the decision. Some projects use 50+ gems and
then
> an
> > incompatible gem can bring considerable slowdown to development. Are
you
> > willing to patch the gems/plugins yourself if they aren''t
compatible? My
> > personal opinion would be continue with development, and upgrade when
the
> > project is on production, because then you''ll be able to
focus on 1 task
> -
> > upgrading, while if you migrate now, you will have to both keep
> developing
> > the functionality, and solve incompatability problems.
>
> All really good points. I am so early in development that upgrading
> turned out not to be a problem. Everything basically just worked.
> Sure, I had to remove/add configuration in various places... make a
> few directories... move some files... etc... but it all just worked.
>
> I think my only big question now concerns the javascript code - where
> do I put page-specific javascript? Since it all gets put into 1
> javascript file, where do I put my code for the individual pages? Or
> do I not worry about it? That seems a bit odd. Do I no longer need
> something like require.js?
>
> I''m just a little confused about how to go about this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On May 29, 8:53 am, Martin Wawrusch
<mar...-qs6+VQBngv1Wk0Htik3J/w@public.gmane.org>
wrote:
> Depending on the kind of site you might want to use mvc views through
> backbone or something similar and launch specific views depending on the
> current page, something like so:
>
> html:
> body class=´users search_page´
> ...
>
> and in your coffeescripts (you do use coffeescript :P)
>
> class UserSearchView extends Backbone.View # or controller
>    ...
>   initialize: ->
>     here goes your page specific initializers
>
> $ ->
>   window.currentView = new UserSearchView if
$(´body.users.search'').length >
> 0
>
> I have never been a huge fan of libs like require.js except for real big
web
> apps, mostly it is better to just dump the whole javascript in one minified
> file.
My project is probably going to turn out to be one big web app ;)

I can work with whatever design Rails wants me to go with... I just
want to make sure what that is.

So if I were to use backbone (I probably will), what is top those
backbone objects from getting instantiated on pages where they aren''t
needed?

With require.js, I was able to put 1 script_include_tag at the bottom
of the page that loaded a javascript file which ignited the rest of
the javascript code for that page. It was like a controller, but for
javascript basically. This ensured that this controller code would
only be executed on this page - and no other.

Now I am at a loss as to how to achieve this without using page-
specific pages. I guess I don''t need Javascript anymore, but
I''m
thinking I will still have to remove this line:

//= require_tree .

Correct?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

>class UserSearchView extends Backbone.View # or controller
>   ...
>  initialize: ->
>    here goes your page specific initializers
>
>$ ->
>  window.currentView = new UserSearchView if
$(´body.users.search'').length >
>0
This solution looks interesting, and it also looks potentially
dangerous. I''m not a fan of string-based rules like this. I guess I
can just get used to it (and of course not rely on the body, but
perhaps a <div id="user_search"> or something like that.

I will play with it. It might be nice to never have to care to include
the script tag at the bottom of page, using require or not.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

I guess I am going to blog about this once I have a bit more time.

In general my observation with websites and javascript is that you have lots
of code that applies to all pages if you structure it right (usage of class
names in css), and very few pages that have intense, page specific code. The
project I am working right now has about 1000 lines of coffeescript for the
search page and maybe 200 for the rest of the site (and some custom jquery
plugins), which makes solutions like the one I proposed rather save. The
class is attached to the body because I am following the *html5*
boilerplate.com/
conventions.


On Sun, May 29, 2011 at 6:18 AM, egervari
<ken.egervari-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >class UserSearchView extends Backbone.View # or controller
> >   ...
> >  initialize: ->
> >    here goes your page specific initializers
> >
> >$ ->
> >  window.currentView = new UserSearchView if
$(´body.users.search'').length
> >
> >0
>
> This solution looks interesting, and it also looks potentially
> dangerous. I''m not a fan of string-based rules like this. I guess
I
> can just get used to it (and of course not rely on the body, but
> perhaps a <div id="user_search"> or something like that.
>
> I will play with it. It might be nice to never have to care to include
> the script tag at the bottom of page, using require or not.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
>
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On May 29, 9:27 am, Martin Wawrusch
<mar...-qs6+VQBngv1Wk0Htik3J/w@public.gmane.org>
wrote:
> I guess I am going to blog about this once I have a bit more time.
>
> In general my observation with websites and javascript is that you have
lots
> of code that applies to all pages if you structure it right (usage of class
> names in css), and very few pages that have intense, page specific code.
The
> project I am working right now has about 1000 lines of coffeescript for the
> search page and maybe 200 for the rest of the site (and some custom jquery
> plugins), which makes solutions like the one I proposed rather save. The
> class is attached to the body because I am following the *html5*
> boilerplate.com/
> conventions.
I''d love to read it. I will try your way and see how it goes. The more
I think about it, the more I like the "if exists on the page, then run
it" strategy. I guess this would let you slap elements in and out of
pages everywhere and the javascript will just continue to work. Pretty
nice.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.