[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Michael Koziarski
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

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Sandofsky
I think *_to_remote belong in a plugin. I can't remember the last time I used one. On Jul 7, 5:04 pm, Clemens [EMAIL PROTECTED] wrote: Nik, unfortunately, IMO it hardly is. First and foremost, UJS4Rails has been unmaintained for more than 1 1/2 years for a simple reason: Dan and Luke think

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Nik Wakelin
@Sandofsky: views dir of project number 1 (irb) : Dir[**/*.rhtml, **/*.html.erb].inject(0) { |total, file| total += `grep -c link_to_remote #{file}`.to_i; } = 29 views dir of project number 2 (irb): Dir[**/*.rhtml, **/*.html.erb].inject(0) { |total, file| total += `grep -c

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Clemens
Koz, thanks for the statements. 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

[Rails-core] old ticket on trac, how to find on lighthouse?

2008-07-08 Thread ss1982
Hi, The following ticket was on trac http://dev.rubyonrails.org/ticket/8886 Were all old tickets moved over to lighthouse and if so is there an easy way to find it. (All attempts so far have failed) Cheers --~--~-~--~~~---~--~~ You received this message because

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Michael Koziarski
You're probably right about getting in trouble, I already feel the accessibility folks will come kicking and screaming if they hear about this! ;-) But seriously: A little proactivity wouldn't hurt here - after all, Rails also created the whole Convention Over Configuration buzz, wasn't it?

[Rails-core] Re: old ticket on trac, how to find on lighthouse?

2008-07-08 Thread Michael Koziarski
The old tickets weren't moved, that's why we've kept trac running. If you want to start working on it, you should either continue to work on trac, or manually move it over to lighthouse. However the sql server adapter isn't maintained with rails anymore. On Tue, Jul 8, 2008 at 1:16 PM, ss1982

[Rails-core] Naruto 408

2008-07-08 Thread mangaboy005
Naruto 408 Naruto 408, One Piece 507, Bleach 329 Hot manga Download The hottest mangas and the latest chapters Manga news, Most popular mangas, Latest mangas, Latest chapters http://english1.isoshu.com/?recommid=1023 http://emanga1.isoshu.com/?recommid=1023

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread James H.
IMHO make the whole JavaScript package, as it currently stands, a plugin. This would be a wonderful step towards having a Prototype, jQuery, MooTools (etc.) package for Rails. The situation with Merb and JavaScript is quite wonderful: pick your own and run with it. There's no helpers, no RJS

[Rails-core] Re: old ticket on trac, how to find on lighthouse?

2008-07-08 Thread Murray Steele
2008/7/8 Michael Koziarski [EMAIL PROTECTED]: However the sql server adapter isn't maintained with rails anymore. To that end, there is a rails-sqlserver-adapter google group that you might want to join to discuss ongoing development of it:

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Pratik
On Tue, Jul 8, 2008 at 2:28 PM, James H. [EMAIL PROTECTED] wrote: IMHO make the whole JavaScript package, as it currently stands, a plugin. There is absoltely no reason/explaination to do so. And I don't see it happening. Many of us use those helpers in most of the projects, and it works for

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Clemens
Given how widely used the current fuctionality is, then we'd need to see much better adoption of the better solution before we could do something like this. If something easier, and more accesible emerges then we can go for it,  but personally I definitely prefer to use link_to_remote over

[Rails-core] Re: config.gem implementation

2008-07-08 Thread Chad Woolley
On Mon, Jul 7, 2008 at 1:20 PM, Dan Manges [EMAIL PROTECTED] wrote: Thoughts? Use GemInstalller from config/preinitializer.rb and I believe all these problems go away (let me know if they don't, and feel free to ask/open bugs). -- Chad --~--~-~--~~~---~--~~ You

[Rails-core] Re: Posting Multipart Forms Over ActiveResource

2008-07-08 Thread Nick Gauthier
Thanks Jatinder, That worked great, although I had to handle my authentication differently. Thanks again for your help. -Nick On Jul 7, 5:01 pm, Jatinder Singh [EMAIL PROTECTED] wrote: Hey Nick, Even I had this requirement of uploading files using some sort of API, but couldn't really

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Michael Koziarski
I understand you're hesitant to completely remove a widely used feature - but what do you think of my 4 concrete suggestions? Heh, good point - Like I said in the ticket, link_to_remote should populate the href by default to provide a sensible fallback. I'm not sure that this *is* a

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Sandofsky
Lack of feature is not a feature. I think it is. Otherwise we'd have ActionWebService, pagination, and acts_as_list in core. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Sujal Shah
Wasn't pagination widely used when it was pulled out? How about auto_complete? in_place_editing? Sujal On Jul 8, 2008, at 1:27 PM, Sandofsky wrote: Lack of feature is not a feature. I think it is. Otherwise we'd have ActionWebService, pagination, and acts_as_list in core.

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Michael Koziarski
Lack of feature is not a feature. I think it is. Otherwise we'd have ActionWebService, pagination, and acts_as_list in core. ActionWebService and pagination were unmaintained with better alternatives out there (REST and will_paginate). acts_as_list was a close call but each of the other

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Sujal Shah
I don't have a strong opinion here, but look at what you just said: Pros for keeping helpers: Lots of projects use them Pros for removing actionwebservice, pagination, etc.: unmaintained, better alternatives exist (e.g. will_paginate) or can be made easily (e.g. auto_complete) The reasons

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Jan De Poorter
I like the idea of extracting the javascript helpers and the javascript files to a plugin. That way we can have a PrototypeJS plugin, a jQuery plugin, a YUI plugin, which all provide the same default helpers (Kind of the way ActiveRecord provides connectors to MySQL/Postgres/...) It

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Michael Koziarski
I like the idea of extracting the javascript helpers and the javascript files to a plugin. That way we can have a PrototypeJS plugin, a jQuery plugin, a YUI plugin, which all provide the same default helpers (Kind of the way ActiveRecord provides connectors to MySQL/Postgres/...) It would

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread DHH
Just to chime in with my 5 cents (yeah, that's right, I just paid an extra three! ;)). 1) I like button_to_remote as an alias for submit_to_remote. 2) I don't think the JS helpers should be a plugin at all. Rails has always been about including a default answer to most common questions at the

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread Anthony Richardson
This has been an interesting discussion. I don't have a strong opinion either way as I don't use the helpers or prototype/scriptaculous. However, if you did want to make the current helpers unobtrusive, with backwards compatibility to current behaviour, couldn't you have the helper output a form

[Rails-core] ActiveModel::Validatable(Total Rewrite, Totally Awesome) - Request for comment on work in progress

2008-07-08 Thread Ruy Asan (rubyruy)
BEHOLD: http://github.com/rubyruy/rails/tree/recursive_errors I didn't really want to come out with this just yet - although I'm 95% certain this is the general architecture I want to go with, I'm only about 60% or so done with the implementation, and only 40% or so done with the testing. I

[Rails-core] Re: JavaScript and URL helpers need some love regarding best practices

2008-07-08 Thread James H.
There is absoltely no reason/explaination to do so. And I don't see it happening. Many of us use those helpers in most of the projects, and it works for us like a charm. [...] Rails is not forcing you to use those helpers or RJS. The notion that there's huge chunks of Rails that may or may