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.
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 
On May 29, 8:12am, egervari [email protected] 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.
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 [email protected]
On May 29, 8:28 am, Gintautas Šimkus [email protected] wrote:
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.
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 [email protected]
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.
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
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.
On May 29, 8:53am, Martin W. [email protected] wrote:
class UserSearchView extends Backbone.View # or controller
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?
On May 29, 9:27am, Martin W. [email protected] wrote:
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.
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.