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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jan 28, 2009 at 14:46, Erwan Barrier <erwan.barrier@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? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Jan 28, 2009 at 1:50 PM, Mislav Marohnić <mislav.marohnic@gmail.com>wrote:> On Wed, Jan 28, 2009 at 14:46, Erwan Barrier <erwan.barrier@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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jan 29, 2009 at 00:25, DHH <david.heinemeier@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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Rails stops generating inline JavaScript? I like the sound of that! :) > Custom microformats and unobtrusive scripting ftwMy 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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:> On Thu, Jan 29, 2009 at 00:25, DHH <david.heineme...@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--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Jan 29, 6:34 pm, Erwan Barrier <erwan.barr...@gmail.com> wrote:> > 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.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---