To me, the greatest gain unobtrusive Javascript provides is
maintainability. You split the client-side logic (that is *all*
Javascript is) from the view for the same reason you split the
controller processing and buisness logic from the view with an MVC
framework. In addition to all Marnen said: your views become much
easier to test; You spend less time adapting the HTML your designer
gives you (or that you mock up yourself); It's *much* easier to focus
on providing an intuitive interface for those with or without
Javascript enabled.
Just a couple specific points:
> 1) what if this menu is part of a view being loaded into an existing
> div, and not part of a fresh page
$(element).live("event", function...)
I'm sure non-JQuery'ers have something similar
> Yeah, because you use ruby shortcuts. The JS still ends up in the page.
> All you have to do is look at the source generated for a rails app page
> (any and all of them) to find more inline javascript than you can shake
> a stick at.
Don't use the RJS helpers, no inline JS. And if you think not using
the RJS helpers is limiting, I doubt you've really explored the powers
JS frameworks.
>>> It still seems to me that it is. Where there is html, there can be
>>> javascript.
>> Yes. There can also be CSS. There *should* be neither.
> WHY!???!?
Semantic markup that knows little about how it'll be displayed is far
easier to maintain, and offers *more* presentational flexibility via
your stylesheets.
On May 29, 7:52 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> Mk 27 wrote:
> > Marnen Laibow-Koser wrote:
>
> >>> It still seems to me that it is. Where there is html, there can be
> >>> javascript.
>
> >> Yes. There can also be CSS. There *should* be neither.
>
> > WHY!???!? You want to make web programming *more* limited that it
> > already is??
>
> No, I want to separate behavior and presentation. That's just good
> architecture.
> Nothing I am recommending makes Web programming any more limited. If
> anything, it has the opposite effect, since it organizes the code
> better.
>
> > I agree "when convienient" but
>
> >> Rather what I'm talking about is simply having <div class="menu"></div>
> >> in your HTML, then do something like
>
> >> window.onload = function () {
>
> > 1) what if this menu is part of a view being loaded into an existing
> > div, and not part of a fresh page
>
> I *think* the principle still works.
>
>
>
> > 2) create_menu_div would imply (or at least, I would hope) to me
> > something a little bit more significant than just assigning some style.
> > I do use a function like this, and it takes an array of choices (for the
> > menu options) and a callback containing a switch(); the number of the
> > choice corresponds to this, so rather than having to write a slew of
> > onclick statements, etc,
>
> > choices = ["do this", "do that", "do both"];
> > create_menu_div(style, choices, parnt, callback);
>
> Not sure I understand from that description. I'll reread when I'm less
> pressed for time.
>
> >>> Also, using an event handler still
> >>> entails putting some javascript in an html page somewhere.
>
> >> Not necessarily. You can use the onload technique (as above) to assign
> >> behavior without a single JS call in the HTML. All you need is the
> >> external <script> tag in the <head>.
>
> > The <head> I would say is part of an html page.
>
> Yes. That's not what I meant. Rather, I meant that the <script> tag
> points to an external file, so there is *not a single line of JS* in the
> HTML file.
>
> I'm sure you already handle CSS this way, with <style> tags pointing to
> external file. Why is it so hard to grasp the concept of doing the same
> for JS?
>
>
>
> >> It's not a paradox at all. It's perfectly feasible, and I know because
> >> I have done it.
>
> > Yeah, because you use ruby shortcuts. The JS still ends up in the page.
>
> Wrong. The complex Ajax work I have done was in an application that did
> not involve Rails, or indeed any other framework with JS helpers. I
> know precisely how much literal JS wound up in the HTML generated by
> that application: none. I made sure of that, and would do it exactly
> the same way again in a similar case, Rails or no Rails.
>
> > All you have to do is look at the source generated for a rails app page
> > (any and all of them) to find more inline javascript than you can shake
> > a stick at.
>
> Yes, if you use Rails' JS helpers without the UJS or Lowpro plugins.
> This is why I don't like to do that. At the very least, use one of
> those plugins to separate your JS and HTML.
>
>
>
> >> Again: it is possible. It is feasible. It's not even particularly
> >> difficult.
>
> > Sure, and again I agree: as convenient. By "not possible" I meant that
> > I sincerely hope that people with your opinion do not come up with a
> > means of *forcing* everyone else to comply, and I do believe that "will
> > not be possible", in fact. Thankfully.
>
> Yeah, I don't know that I'd want that either. Choice is a good thing,
> but with choice comes responsibility -- just because you *can* write JS
> inline doesn't mean you should.
>
> OTOH, I really wouldn't be at all unhappy if inline JS just dropped off
> the face of the earth. It's not an appropriate way to write
> maintainable code, and it causes problems on the client side as well.
>
>
>
> > -MK
>
> > ps. with your penchant for waving credentials and experience, the
> > biggest question in my mind would be why the simple answer Rob gave was
> > evidently out of your range...
>
> Why? Simple: because I haven't done a lot with Rails' JS helpers --
> just enough to know that they generate more inline JS than I'm
> comfortable with.
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> [email protected]
> --
> Posted viahttp://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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
