> As I mentioned in my first post, IMO it would probably be best to just > totally remove this stuff from Rails because it kinda hides bad > practice behind some framework code. In most areas, Rails evangelizes > best practices and opinions by making it more work for the programmer > to break the rules (think of set_table_name, for example). But in the > case of these helpers it's actually less work to break the rules (or, > rather, guides - speaking of unobtrusive javascript) than to follow > them.
I'll probably get in trouble for this, but I don't think that unobtrusive javascript has yet to obtain the status of undeniable best practise that you seem to be ascribing to it. The current helpers are a pragmatic solution to what is otherwise an incredibly frustrating job, and the code they generate may be 'obtrusive' but it works just fine. The specific case you mentioned in your patch sounds interesting but I'm not sure that the assumption of being able to make non-AJAX to the ajax url is a valid one. <a href="/people/1"> isn't the same thing as a link which submits a DELETE request to the same URL. > Especially those folks new to Rails (and probably not all that > experienced in web development in general) may be led astray where we > could easily guide them down the right or at least better way than the > current one. What are the current practical problems which the existing helpers cause? > I'm not saying that Rails should be more newbie-friendly > - IMO the barriers of entry have already become too low if you take a > look at the questions asked at RailsForum or WWR. I strongly disagree with this, while it may be satisfying to feel superior about people finding it hard to get started, that's not the way successful communities behave. The barriers to entry should be *lower* not higher. > What I'm saying is > that Rails, to me, is a whole lot of good practices and rules and it > should be consistent in that way without any exceptions - not even > something as "humble" as the helpers. > > Anyways, I'd love to hear more opinions on the topic. > > Best, > - Clemens > > On Jul 8, 12:11 am, "Nik Wakelin" <[EMAIL PROTECTED]> wrote: >> Hi Clemens, >> >> Isn't this the kind of thing that the UJS for Rails plugin >> (http://ujs4rails.com/) already does? >> >> Cheers, >> >> Nik >> >> >> >> On Tue, Jul 8, 2008 at 2:13 AM, Clemens <[EMAIL PROTECTED]> wrote: >> >> > Folks, >> >> > my original intent for this post was to promote a patch that I >> > submitted to Lighthouse because Pratik marked it as invalid and told >> > me to raise the issue here if I found it to be important. Please find >> > the ticket >> > here:http://rails.lighthouseapp.com/projects/8994/tickets/517-link_to_remo.... >> >> > However, I've pondered the issue over the last few days and I think >> > the root of the problem is actually way deeper than I originally >> > thought. I think, Rails' JavaScript helpers and URL helpers need a >> > certain amount of refactoring for one really simple reason: Pretty >> > much everywhere, Rails follows best practice approaches and advocates >> > a really clean and professional way of "doing things right". Two >> > exceptions to that rule are parts of the JavaScript helpers and URL >> > helpers. >> >> > Let me be a little bit more specific about issues that I think should >> > at least be considered: >> > - Like I said in the ticket, link_to_remote should populate the href >> > by default to provide a sensible fallback. >> > - submit_to_remote should be renamed or at least aliased to >> > button_to_remote just for the sake of being consistent with link_to/ >> > link_to_remote. >> > - link_to/link_to_remote helpers should at least raise some kind of >> > notice when used with :method => :post/:put/:delete. Links shouldn't >> > be used to post/put/delete on a server. Yes, I know that it actually >> > wraps the whole thing inside a form, but still it's not a good idea. >> > The fact that potentially "destructive" actions should be handled with >> > a button should definitely be advocated. >> > - Not strictly related to the helpers: While I think that mostly >> > beginners use the scaffold feature, I feel that it still should >> > reflect best practices. Therefore, the delete link should be made into >> > a button. >> >> > Now while most if this stuff isn't an issue for me personally (and it >> > probably neither is for you guys), I feel that there's definitely room >> > for improvement. If I was to decide, I'd totally remove all >> > *_to_remote stuff from the core and force people to write their >> > JavaScript by hand and/or use lowpro. But I think, the above things >> > would be quite easy to implement without being a harsh change. >> >> > I kept this post short by intention in order for you to really read >> > it, but of course I've got some more ideas regarding these helpers. >> > I'd be more than happy to provide patches if you agree with me that >> > this is an issue worth being addressed. >> >> > Please let me know what you think. >> >> > Best, >> > - Clemens >> >> -- >> Nik Wakelin >> [EMAIL PROTECTED] > > > -- 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 [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-core?hl=en -~----------~----~----~----~------~----~------~--~---
