Mk 27 wrote: [...] > 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.
You are absolutely wrong. Since inline JS, by its very nature, is much harder to refactor, in many, many types of cases, inline JS will lead to significantly more code than unobtrusive external JS. Anyway, I'm not sure conciseness is as high a priority as ease of maintenance (although they do sometimes coincide), so your point is of dubious relevance. > > 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. No. Just iterate over the affected DOM elements and apply an appropriate abstraction. You said you were snobbish about JS as compared to "real languages". Well, guess what -- JS is a "real" language, and quite a powerful one too, but you can't benefit from that fact unless you treat it as a "real" language. That means writing complete routines in one place, not scattered bits of inline code. [...] > 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. It is always feasible. It is (virtually) always worth doing. Stop complaining about it and try writing a sample page or two (with or without Rails) while keeping JS out of the HTML. I guarantee that both your JS and your HTML will be the better for it. > 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. They have significance for every nontrivial case. > You are not > talking about any improvement in functionality or performance, after > all. Wrong again. > > I would hate to consider a case where an author decided *not* to do > something because it required inline js. Read my lips: *NOTHING* REQUIRES INLINE JS! Anything doable with inline JS can also be done without it. > That would be ass backward > blind conformism. Perhaps it would be, but it's a straw man, since it will never happen. > > -MK Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org -- 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 -~----------~----~----~----~------~----~------~--~---
