I want append custom query parameters to my pagination links, like
?page=1&foo=bar. I can’t quite figure out how to do this with the
pagination_links helper, although I believe the API says you should be
able to:
pagination_links(paginator, options={}, html_options={})
options are:
:params: any additional routing parameters for page URLs
Has anyone tried this?
thanks,
jeff
Jeff C. wrote:
I want append custom query parameters to my pagination links, like
?page=1&foo=bar. I can’t quite figure out how to do this
Here’s what I did to implement a prefix search that if I understand your
request has a similar requirement - in the controller action spec (.rb
file) if the prefix parameter was set it would use the following custom
paginator instead of the one generated by the scaffold generator:
@performer_pages = Paginator.new self,
Performer.count, 25, @params[‘page’]
@performers = Performer.find( :all,
:conditions => [“Performer >= ?”, params[:prefix] ],
:order => “Name ASC”, :limit =>
@performer_pages.items_per_page,
:offset => @performer_pages.current.offset )
Then in the view (rhtml), to create the next & previous links I add the
prefix parameter to the URL if necessary:
<% if params[:prefix] %>
<%= link_to ‘Previous page’, { :prefix => params[:prefix], :page =>
@performer_pages.current.previous } if @performer_pages.current.previous
%>
<%= link_to ‘Next page’, { :prefix => params[:prefix], :page =>
@performer_pages.current.next } if @performer_pages.current.next %>
<% else %>
<%= link_to ‘Previous page’, { :page =>
@performer_pages.current.previous } if @performer_pages.current.previous
%>
<%= link_to ‘Next page’, { :page => @performer_pages.current.next } if
@performer_pages.current.next %>
<% end %>
Hope this helps.
PS: Only problem with my custom paginator is that while it seems to be
creating the next & previous links appropriately when they are required,
it creates the ‘next’ link when one is not required. Whereas it
appropriately generates the ‘previous’ link only when needed (i.e., not
on the first page of results), it consistently INappropriately generates
the ‘next’ link even when one is not required (i.e., the result for the
‘next’ page view is empty).
I suspect that this bug is somehow due to the way I generate the
paginator, whereas I gather all you’re asking for is about the creating
the next & previous links. Funny, because I copied this syntax exactly
from the docs.
Jeff C. wrote:
thanks,
jeff
pagination_links(paginator, {:params => {:foo =>
“bar”}}.update(options))
should work.
Another way to do this is:
pagination_links_each(paginator, options) {|n| “#{n}” }
See http://railsexpress.de/blog/articles/2005/11/04/faster-pagination
– stefan
–
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: railsexpress.de
Greetings everyone,
ActiveRecord makes handling errors in your views pretty easy, but they
lack
the customization that most would want. Their display order doesn’t
match
the order of elements of your form and the humanizing of column names
only
works well for simple column names. This plugin adds 5 new attributes to
the
error_messages_for() function.
:priority - Allows you to specify the display order of the errors
:attr_names - Override the default humanizing of attributes with your
own
attribute → name mapping.
:defaults - Boolean, allows you to extend :attr_names and customize the
error message that is displayed. By default, :attr_names only changes
the
display name of the attribute. The real beauty of this one, is that you
can
validate your fields with one call to validates_* :attr, :attr, :attr
and
provide a unique error message for each. Currently, you would have to
call
validates_* for each attribute and pass in your custom :message.
:header - A string to override the header of the error container. It
will
perform substitutions for the error count and model name using a simple
syntax of {count} and {object}.
:sub_header - A string to override the sub header in the error
container.
You can download the plugin and view usage information at:
http://railtie.net/articles/2006/01/26/enhancing_rails_errors
Bob S.
Ruby on Rails Evangelist
http://www.railtie.net/
Bob-
Looks very nice indeed! Thanks for this.
One thing I wanted to inform you of though is that it seems you have
accidentally highjacked other threads a few times recently. The way
this happens is when you just hit reply on another thread from the
list and then change the subject line. Its an easy mistake to fall
into but it really messes up threaded email readers and your new
announcement will more then likely get lost in the other thread that
was highjacked and not seen by as many people as it would have been
if you started a new thread. I’m not trying to be harsh or anything
here just wanted to give you a head up. Next time you want to make a
new thread , please start a brand new email in your client without
replying to another thread and send it to the list. This way threaded
clients will be able to do what they are good at. What happens when
you hit reply and just change the subject is the hidden in-reply-to
header doesn’t change and still references the old thread.
Just a heads up man, no offence intended ;) And I really do like the
plugin and other announcements you have made recently so i think you
will get more people to see them if they are in a new thread 
Cheers-
-Ezra
On Jan 26, 2006, at 10:22 PM, Bob S. wrote:
error_messages_for() function.
changes the
perform substitutions for the error count and model name using a
-Ezra Z.
Yakima Herald-Republic
WebMaster
509-577-7732
[email protected]
AH!, yep, you busted me. Ok, I’ll stop being lazy and type the mailing
address into a new post 
Thanks Ezra.
PS: I would certainly hope that the world isn’t bad enough yet that
someone
would take offense when someone tells them how to do something properly.
Bob S.
http://www.railtie.net/
Hey, nice. I’ll try it out. Thanks!
-Bill
Ezra Z. wrote:
was highjacked and not seen by as many people as it would have been if
you will get more people to see them if they are in a new threadCheers-
-Ezra
I’ve seen this happen a large number of times and it messes up the
automatic
threading that Thunderbird and other mail clients do. This list gets
enough
traffic as it is without making manging the volume any harder
Is there a way we can handle this? Do people think it’s appropriate to
send a
private note to the person?
On the mailing lists I manage, this doesn’t happen, but if it did happen
consistently, I would ping the person privately about it and request
that they
start new threads.
Regards,
Blair
–
Blair Z., Ph.D.
[email protected]
Subversion training, consulting and support
http://www.orcaware.com/svn/
Stefan, you are correct, that is the answer I was looking for. However,
it gets trickier if you have a two-dimensional set of params, like:
@params[:foo][:bar]
because the Rails name for the corresponding form element would be
name=“foo[bar]”; when it gets appended to the query string, the “[” and
“]” get HTML-escaped and you can no longer get that param from the query
string. Is there a solution for that?
thanks,
jeff
Stefan K. wrote:
pagination_links(paginator, {:params => {:foo =>
“bar”}}.update(options))
I’ve seen this happen a large number of times and it messes up the
automatic threading that Thunderbird and other mail clients do.
The risk for the hijacker is that his/her message won’t be read by
people who ignore the thread they’ve just hijacked.
For example, I _K_ill (automatically ignore) all the threads about
Oracle, SqlServer, Postgress, Ubuntu, etc…
Alain
On Fri, Feb 17, 2006 at 07:24:07PM +0100, Alain R. wrote:
> I've seen this happen a large number of times and it messes up the > automatic threading that Thunderbird and other mail clients do.The risk for the hijacker is that his/her message won’t be read by
people who ignore the thread they’ve just hijacked.
For example, I _K_ill (automatically ignore) all the threads about
Oracle, SqlServer, Postgress, Ubuntu, etc…
This is an education issue. People who don’t use threaded mailreaders
don’t understand why this is important. Most common mailers don’t give
you the option of removing the In-Reply-To header from outgoing
replies, and in the interface, there’s no difference between a reply
and a new message.
I put together a blog post a while ago that illustrates this:
–
- Adam
** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
Blair wrote:
Ezra wrote:
What happens when you hit
reply and just change the subject is the hidden in-reply-to header
doesn’t change and still references the old thread.
[BW] Wow! That’s excellent information, Ezra. Thank you. I’ve always
been baffled by the way threads just ‘disappear’ sometimes, especially
when
I can see there’s more to them just looking at the unfiltered list. It
never occurred to me that a hidden header was there. And I’m absolutely
sure I’ve comitted the same mistake you’ve so kindly explained ;-p
Is there a way we can handle this? Do people think it’s appropriate to
send a
private note to the person?
[BW] As long as the sender has the emotional maturity to approach the
topic
at hand in a helpful, non-accusatory fashion, I think it’s entirely
appropriate to point out these things. The real world analogy is…
would
you rather someone quietly pulled you aside and let you know your zipper
was
open? Or would you prefer everybody just let you walk around the mall
that
way until …? This community depends on trust. Helpful, honest
communication fosters trust. I’m going to save Ezra’s email to remind
me
how to handle the conversation.
Best regards,
Bill
Adam F. wrote:
This is an education issue. People who don’t use threaded mailreaders
don’t understand why this is important. Most common mailers don’t give
you the option of removing the In-Reply-To header from outgoing
replies, and in the interface, there’s no difference between a reply
and a new message.I put together a blog post a while ago that illustrates this:
The question is, should we educate the people on the list? And if so,
how?
I don’t just want to start emailing people when they do this, unless the
group
decides that’s acceptable and appropriate to do so.
Regards,
Blair
–
Blair Z., Ph.D.
[email protected]
Subversion training, consulting and support
http://www.orcaware.com/svn/
On Fri, Feb 17, 2006 at 10:42:07AM -0800, Blair Z. wrote:
[…]
The question is, should we educate the people on the list? And if so, how?
I don’t just want to start emailing people when they do this, unless the
group decides that’s acceptable and appropriate to do so.
I suppose that would be up to the admins regarding whether “don’t
botch up the thread structure if you change the subject line” is a
rule or not. I’d vote for yes, personally.
–
- Adam
** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
On Fri, Feb 17, 2006 at 11:12:08AM -0800, Estelle W. wrote:
[…]
Is it a large proportion of people who are affected? Perhaps it would
be possible to setup automatic email warnings when a subject is
changed but the In-Reply-To header isn’t changed?
More particularly, it would have to be “if the subject doesn’t match
the message referenced by the in-reply-to header”. It’s not terribly
difficult to do, but I don’t think it’s a built-in option with
mailman. Perhaps it should be.
Or perhaps people could be given this info when they first sign up.
Since the popularity of this list will steadily increase, I doubt it
will be possible to keep everyone informed by manually sending out
individual emails.
Agreed. It should be one of the list rules and announced on the front
page.
–
- Adam
** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
How about adding the following to the automatically appended footer:
“List etiquette: only use “reply” when replying to a thread; create a
blank message when
asking a new question.”
Then again, if I had a dollar for every time someone has asked how to
unsubscribe from a
list with a “to unsubscribe from this list: …” footer, I’d, well, I’d
have some money.
b
I just use Gmail so I didn’t realise that there was anything linking
the threads other than the subject.
Is it a large proportion of people who are affected? Perhaps it would
be possible to setup automatic email warnings when a subject is
changed but the In-Reply-To header isn’t changed?
Or perhaps people could be given this info when they first sign up.
Since the popularity of this list will steadily increase, I doubt it
will be possible to keep everyone informed by manually sending out
individual emails.
Estelle.
On 2/17/06, Adam F. [email protected] wrote:
I suppose that would be up to the admins regarding whether “don’t
botch up the thread structure if you change the subject line” is a
rule or not. I’d vote for yes, personally.
As far as rules go, somewhere near #1 should be “no top posting.”
ooooh don’t even go there…
Estelle W. wrote:
will be possible to keep everyone informed by manually sending out
individual emails.
I’ve thought about this a bit, and it meshes with another idea I had
recently… Why don’t we have a regularly-posted FAQ? That would be
the appropriate place for it. I wouldn’t mind handling it, if there was
demand.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs