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-Koser
http://www.marnen.org
[email protected]
--
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 [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
-~----------~----~----~----~------~----~------~--~---
