javascript agnostic feature in rails

8 views
Skip to first unread message

Erwan Barrier

unread,
Jan 28, 2009, 8:46:05 AM1/28/09
to Ruby on Rails: Core
Hi,

I'd like to work on the javascript agnostic feature, but need some
clarifications regarding the implementation before digging too deep in
the code.

1) I've seen two propositions do detach the js framework specific code
from the rails core:

* Yehuda suggested that we have a javascript file for each framework
(prototype.rails.js, jquery.rails.js, etc...) which implement the
helpers. Rails js helpers would generate js code, implemented by
prototype.rails.js or another depending on the choosen framework.

* Clemens in this post (http://tinyurl.com/carrpv) suggest that we
abstract the js code generation by having an
AbstractJavaScriptGenerator which sits as a parent for
PrototypeGenerator, JQueryGenerator, etc...

IMO Yehuda's approach is more elegant, because as he says, the js is
completely decoupled from the rails core, and anyone can customize the
js helpers to fit their needs, but I'd like to hear your opinions.

2) I don't know for sure what would be the preferred way to distribute
it.
If we go with Clemens' approach, it does make sense to encapsulate a
js plugin as a rails plugin, as it contains ruby code,
but I'm not sure with Yehuda's approach, as it is just some js files.
It could be handled with a set of rake tasks, although I prefer to put
it in a gem to avoid downloading the js files each time I create a
project.

Mislav Marohnić

unread,
Jan 28, 2009, 2:50:42 PM1/28/09
to rubyonra...@googlegroups.com
On Wed, Jan 28, 2009 at 14:46, Erwan Barrier <erwan....@gmail.com> wrote:

 * Yehuda suggested that we have a javascript file for each framework
(prototype.rails.js, jquery.rails.js, etc...) which implement the
helpers. Rails js helpers would generate js code, implemented by
prototype.rails.js or another depending on the choosen framework.

So Rails would generate the same set of JavaScript code which would use some kind of an API abstracting away jQuery and Prototype? Could work in theory, but then you're ruining the point of difference between JavaScript libraries -- different APIs.  Prototype and jQuery have -- for the most part -- same features; their biggest difference is the API which appeals to different people for different reasons.

If you abstract that away, how will you decide on how this "adapter" thing feels -- Prototypish or jQuery-ish?

David Masover

unread,
Jan 28, 2009, 3:02:21 PM1/28/09
to rubyonra...@googlegroups.com
On Wed, Jan 28, 2009 at 1:50 PM, Mislav Marohnić <mislav....@gmail.com> wrote:
On Wed, Jan 28, 2009 at 14:46, Erwan Barrier <erwan....@gmail.com> wrote:

 * Yehuda suggested that we have a javascript file for each framework
(prototype.rails.js, jquery.rails.js, etc...) which implement the
helpers. Rails js helpers would generate js code, implemented by
prototype.rails.js or another depending on the choosen framework.

So Rails would generate the same set of JavaScript code which would use some kind of an API abstracting away jQuery and Prototype?

If that's the case... I assume the purpose of these helpers is that we'd rather be writing Ruby than Javascript. If that's geneally true, I would think the API would be easier to build and maintain in Ruby than Javascript -- and it would probably mean the code that ultimately gets sent to the client is smaller, lighter, and cleaner.

The only advantage I see of building it in Javascript is to also decouple it from Ruby -- to make a One True Javascript API, which any server-side framework, in any language, can generate code for.

DHH

unread,
Jan 28, 2009, 6:25:38 PM1/28/09
to Ruby on Rails: Core
> 1) I've seen two propositions do detach the js framework specific code
> from the rails core:
>
>   * Yehuda suggested that we have a javascript file for each framework
> (prototype.rails.js, jquery.rails.js, etc...) which implement the
> helpers. Rails js helpers would generate js code, implemented by
> prototype.rails.js or another depending on the choosen framework.

Yes, this is exactly what we should have. So remote_form_for should
just have either a special class, like rails_remote_form, or a special
attribute, ala remote=true. The JS drivers will then know to look for
that class/attribute and wire the behavior in automatically with their
new onload/dom watcher hooks.

So Rails should never really generate any JS for these helpers. Just
decorate them with the proper class names/attributes. Then every JS
library can write a driver that'll look for these Rails specific clues
and wire them up.

Mislav Marohnić

unread,
Jan 28, 2009, 9:36:47 PM1/28/09
to rubyonra...@googlegroups.com
On Thu, Jan 29, 2009 at 00:25, DHH <david.he...@gmail.com> wrote:

So Rails should never really generate any JS for these helpers. Just
decorate them with the proper class names/attributes.

Rails stops generating inline JavaScript? I like the sound of that! :)

Custom microformats and unobtrusive scripting ftw

Michael Koziarski

unread,
Jan 28, 2009, 10:19:38 PM1/28/09
to rubyonra...@googlegroups.com
> Rails stops generating inline JavaScript? I like the sound of that! :)
> Custom microformats and unobtrusive scripting ftw

My only concern with this approach is the enormous amount of
bikeshedding that will no doubt take place. However custom
microformats and default implementations in prototype and jquery, and
we've 'won' from my POV :)


--
Cheers

Koz

Clemens

unread,
Jan 29, 2009, 4:48:07 AM1/29/09
to Ruby on Rails: Core
Obviously, I like that too - otherwise I wouldn't have made the
suggestion half a year ago! :-) Make sure that you contact me as soon
as something's decided - I'd be happy to help implementing this!

- Clemens

On Jan 29, 3:36 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:

Erwan Barrier

unread,
Jan 29, 2009, 12:34:11 PM1/29/09
to Ruby on Rails: Core
> So Rails should never really generate any JS for these helpers. Just
> decorate them with the proper class names/attributes.

Ok, I'll start working on this in the next few days and keep you
updated on the progress.

> Obviously, I like that too - otherwise I wouldn't have made the
> suggestion half a year ago! :-) Make sure that you contact me as soon
> as something's decided - I'd be happy to help implementing this!

Clemens, your help is welcome, I contact you as soon as I have free
time to work on this.

tored...@gmail.com

unread,
Feb 5, 2009, 3:36:27 PM2/5/09
to Ruby on Rails: Core
I wrote something like this for Prototype a while back:

http://github.com/toretore/experiments/blob/b1b1a93370762cf95ff50254c6cf84fe143d6368/unobtrusive-rails/public/javascripts/application.js

Example HTML here:

http://github.com/toretore/experiments/tree/b1b1a93370762cf95ff50254c6cf84fe143d6368/unobtrusive-rails/app/views/horses

It might not be exactly what's imagined in this thread, but it might
provide some ideas or be of use otherwise. It works quite well up
until a point where the complexity doesn't allow you to be completely
unobtrusive and not have to write JavaScript. A hacked in some rather
ugly solutions where you can add onFoo handler code by putting them in
custom attributes, but you'd probably be better off just writing the
JS yourself at this point. The JS is written to be modular and
reusable so for example you can instantiate a Rails.RemoteForm
manually and customise it.

Tore
Reply all
Reply to author
Forward
0 new messages