>From what I've read this issue should really hinge on the scale of a project; if you have a whole team of developers whose membership is subject to change, things like compartmentalization and generic maintainability have to be top priorities.
However, "getting the inline js" out will inevitably increase the actual codebase of the project as whole, because you will have to add *more* lines to your external scripts than you would have used in the page source by inlining in *at least some* (if not quite a few) cases. And please, do not hand me some basic case involving onload(), and claim "oh no, it could never be more coding, look...". Certainly, it could never, ever, logically be *less* coding. Going back to the example to which I have been referring, you would have to throw that whole function out and use a combination of the simple css classing mentioned by marlen with "cut paste and modify"ing the html that would have been the majority of the output of the function. This added effort will no doubt be justified and enabled by a large scale, team oriented project. However, if you are the sole author and maintainer, the extent to which you do this (spend extra time coding to compartmentalize all the javascript) should really be tempered by the feasibility of doing so. I'm down with Occam's Razor here in that introducing a complication is a bad idea if the justification is purely about "universal" policies of style that have little significance for the case at hand. You are not talking about any improvement in functionality or performance, after all. I would hate to consider a case where an author decided *not* to do something because it required inline js. That would be ass backward blind conformism. -MK -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
