It seems counter intuitive IMHO to feature RESTful resources yet have
delete as a link. The same way RESTful resources teach good design by
default, a proper delete would also.
On Jul 9, 4:57 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > Correct me if I'm wrong but a little CSS can make
> I like the spirit of that. I kinda wonder if it becomes a little too
> magical. Some times the fallback URL will be set, some times it won't.
> And if the implementor hasn't considered this and used a respond_to
> block, expecting that all calls will be JS, then the non-JS user will
> just end u
> > 1) I like button_to_remote as an alias for submit_to_remote.
>
> I've just posted a patch
> tohttp://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/58...
Applied (with button_to_remote being the primary, submit_to_remote
being the alias). Thanks!
> > 3) Requiring all post/delet
> Question to everyone: Would it make sense to only default the :href
> attribute to the value of :url if the link_to_remote handles a GET
> request but leave it at "#" for POST/PUT/DELETE since they're likely
> to be wrong anyways?
Try a patch for this and see what people think. It sounds good
> Wouldn't this defeat the entire purpose of *not* using a link. The
> rationale as I understand it is 'links should be safe to click'. If
> it looks like a link, acts like a link, but still isn't safe, then
> we're worse off than with the current implementations. It still
> surprises people bu
> Correct me if I'm wrong but a little CSS can make a button look like a
> link and even behave like one (including a hover effect). I've only
> tried it in Safari and FF3 for the moment but I think I remember that
> it worked in IE6/7 just fine.
Wouldn't this defeat the entire purpose of *not* u
> The notion that there's huge chunks of Rails that may or may not be
> used or are being needlessly loaded makes me squirm a bit.
Methods never called are hardly going to break the bank on performance
or memory usage. There's about a billion other things that should be
higher up your squirm lis
> Correct me if I'm wrong but a little CSS can make a button look like a
> link and even behave like one (including a hover effect). I've only
> tried it in Safari and FF3 for the moment but I think I remember that
> it worked in IE6/7 just fine.
Another possibility is to have button_to_remote ac
> 1) I like button_to_remote as an alias for submit_to_remote.
I've just posted a patch to
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/581-button_to_remote-aliases-submit_to_remote
> 3) Requiring all post/delete actions to be buttons is a personal
> choice that you're more
> 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
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 i
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 in
> 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
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
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
>> 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
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.
> >
-
> 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 t
> 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 s
> 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
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
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 equ
> 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
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 incredi
@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
>
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
> 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
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 that JavaScript should be written separately from the
app anyways. I'd have to say that I totally agree.
As I mentioned in my first post, IM
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 be
29 matches
Mail list logo
