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.

On Wed, Jan 28, 2009 at 14:46, Erwan Barrier <erwan.barr...@gmail.com>wrote:

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?

On Wed, Jan 28, 2009 at 1:50 PM, Mislav Marohnić
<mislav.maroh...@gmail.com>wrote:

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.

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.

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

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:

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

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

I wrote something like this for Prototype a while back:

http://github.com/toretore/experiments/blob/b1b1a93370762cf95ff50254c...

Example HTML here:

http://github.com/toretore/experiments/tree/b1b1a93370762cf95ff50254c...

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

On Jan 29, 6:34 pm, Erwan Barrier <erwan.barr...@gmail.com> wrote: