Plugins

Comments and changes to this ticket

• 

  Chris Wanstrath July 17th, 2007 @ 06:11 PM

  • → State changed from “new” to “open”
  • → Assigned user changed from “Chris Wanstrath” to “Mislav”
• 

  Matt Aimonetti September 28th, 2007 @ 12:52 PM

  I don't think the plugin itself should handle any ajax calls.

  simply use unobtrusive javascript and you can achieve the same result in less than 5 minutes without hacking anything ;)

  http://railsontherun.com/2007/9/...

  And I'm pretty sure you can probably do the same with Prototype only, Mislav?

  -Matt

• 

  Mislav September 29th, 2007 @ 01:21 AM

  • → Title changed from “[Will Paginate][Patch] Ajax Support” to “Ajax Support”
  • → State changed from “open” to “invalid”

  I agree with Matt. I kept this open to give me time to think in what way could I help Ajax pagination ... I realized that the user is on his own, because I'm definitely not generating JavaScript in the view (I know that Rails does, but I don't).

• 

  Ayyanar December 16th, 2007 @ 12:41 PM

  Hi, I updated my views_helper.rb with the lines from will_paginate_with_ajax_calls.diff. Iam not able to get the pagination working. So many errors. I attached my view_helpers.rb. Plz let me know where Iam missing.

• 

  Tom December 13th, 2007 @ 08:41 AM

  The lowpro.js approach works great if you only have one pagination area on a page. But I have a couple of cases where I'd like to have more than one paginator on the page which would need to be handled via different actions. And will_paginate uses the params from the current template to generate the URL used by the paginator. So I am stuck with one action for all paginators and no way to differentiate between them.

  Can you give us a way to override the URL used to create the links in will_paginator?

• 

  bdoyle December 13th, 2007 @ 09:44 AM

  @Tom

  I had this same problem and I modified the will paginate code to take a url in the options and it's working great. In my template file I do something like:

  <%= will_paginate @guides, :url => {:action => 'show_guides', :login => params[:login] }, :class => 'author_guides' %>

  I had to make a slight change in the LinkRenderer#page_link_or_span method:

  def page_link_or_span(page, span_class, text)

  unless page

  @template.content_tag :span, text, :class => span_class

  else

  1. page links should preserve GET/POST parameters

  if @options[:url]

  @options[:url][:page] = page

  @template.link_to text, @options[:url]

  else

  @template.link_to text, @template.params.merge(param => page != 1 ? page : nil)

  end

  end

  end

• 

  Clemens April 22nd, 2008 @ 02:18 PM

  I stumbled across this ticket looking for the exact same thing.

  I haven't come up with a solution yet, but I think the best way would be to write your custom renderer (like WillPaginate::ViewHelpers::LinkRenderer) to render remote links instead of regular ones. After that, AJAX pagination is just a simple <%= will_paginate @posts, :renderer => "AjaxPaginationRenderer" %> away (or one could set it up as the default renderer in environment.rb or an initializer).

• 

  Aketzu May 20th, 2008 @ 10:57 PM

  I solved it with little patch to LinkRenderer.page_link_or_span()

      def page_link_or_span(page, span_class, text = nil)
        text ||= page.to_s
        classnames = Array[*span_class]
  
        if page and page != current_page
          if @options[:update] then
            @template.link_to_remote text, {:url => url_for(page), :method => :get, :update => @options[:update]}, {:rel => rel_value(page), :class => classnames[1] }
          else
            @template.link_to text, url_for(page), :rel => rel_value(page), :class => classnames[1]
          end
        else
        @template.content_tag :span, text, :class => classnames.join(' ')
        end
      end
  

  and then just use <%= will_paginate @permits, :update => :entries %>

• 

  Clemens May 20th, 2008 @ 11:37 PM

  Aketzu:

  Not the best way, I think, especially because your not supplying a :href option for the link_to_remote which makes it unusable for people with JavaScript deactivated. Plus sometimes you may want not only to run Ajax.Updater (which :update => something does) but a real Ajax.Request ...

  I've come to like Matt's lowpro approach - it's clean and it just works! :)