Rails - Jan 2006 - pagination_links help

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

-- 
Posted via http://www.ruby-forum.com/.

Jeff Cole 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.


-- 
Posted via http://www.ruby-forum.com/.

Jeff Cole 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 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
>
>   
pagination_links(paginator, {:params => {:foo =>
"bar"}}.update(options))

should work.

Another way to do this is:

pagination_links_each(paginator, options) {|n| "<a 
href=''?page=#{n}&foo=bar''>#{n}</a>" }

See http://railsexpress.de/blog/articles/2005/11/04/faster-pagination


-- stefan

-- 
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml

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 Silva
Ruby on Rails Evangelist
http://www.railtie.net/

Hey, nice. I''ll try it out. Thanks!
-Bill

On 1/27/06, Bob Silva <me@bobsilva.com> wrote:
>
> 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 Silva
> Ruby on Rails Evangelist
> http://www.railtie.net/
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060127/33e17d4c/attachment.html

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 Silva wrote:
> 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 Silva
> Ruby on Rails Evangelist
> http://www.railtie.net/
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

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 Silva
http://www.railtie.net/

> -----Original Message-----
> From: rails-bounces@lists.rubyonrails.org [mailto:rails-
> bounces@lists.rubyonrails.org] On Behalf Of Ezra Zygmuntowicz
> Sent: Friday, January 27, 2006 9:49 AM
> To: rails@lists.rubyonrails.org
> Subject: Re: [Rails] [ANN] Rails Plugin to enhance
> ActiveRecordserror_messages_for method
> 
> 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 Silva wrote:
> 
> > 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 Silva
> > Ruby on Rails Evangelist
> > http://www.railtie.net/
> >
> >
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> -Ezra Zygmuntowicz
> Yakima Herald-Republic
> WebMaster
> http://yakimaherald.com
> 509-577-7732
> ezra@yakima-herald.com
> 
> 
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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 Kaes wrote:
>>   
> pagination_links(paginator, {:params => {:foo => 
> "bar"}}.update(options))
> 
-- 
Posted via http://www.ruby-forum.com/.

Ezra Zygmuntowicz wrote:
> 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
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 Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

> 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 Ravet
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:

http://fieldsnyc.livejournal.com/11369.html


-- 
				- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki
[ http://del.icio.us/fields ] ............. Links

Adam Fields wrote:
> On Fri, Feb 17, 2006 at 07:24:07PM +0100, Alain Ravet 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:
> 
> http://fieldsnyc.livejournal.com/11369.html
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 Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/

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, Blair Zajac <blair@orcaware.com>
wrote:
> Adam Fields wrote:
> > On Fri, Feb 17, 2006 at 07:24:07PM +0100, Alain Ravet 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:
> >
> > http://fieldsnyc.livejournal.com/11369.html
>
> 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 Zajac, Ph.D.
> <blair@orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Blair wrote:
> Ezra wrote:
<snip>
> > 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

<snip>
> 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

On Fri, Feb 17, 2006 at 10:42:07AM -0800, Blair Zajac 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 ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki
[ http://del.icio.us/fields ] ............. Links

On Fri, Feb 17, 2006 at 11:12:08AM -0800, Estelle Winterflood 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 ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... 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


Adam Fields wrote:
> On Fri, Feb 17, 2006 at 10:42:07AM -0800, Blair Zajac 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.
>

On 2/17/06, Adam Fields <rails23049809@aquick.org>
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....

James Ludlow wrote:
> On 2/17/06, Adam Fields <rails23049809@aquick.org> 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."
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Estelle Winterflood wrote:
> 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.
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.

-- 
Alex

On Sat, Feb 18, 2006 at 02:42:47PM +0000, Alex Young wrote:
[...]
> 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.
Do you mean FAQ about the list, or FAQ from the list?


-- 
				- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki
[ http://del.icio.us/fields ] ............. Links

Adam Fields wrote:
> On Sat, Feb 18, 2006 at 02:42:47PM +0000, Alex Young wrote:
> [...]
>> 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.
> 
> Do you mean FAQ about the list, or FAQ from the list?
> 
It could be both.

The Python list has a weekly mail which contains a selection of 
interesting going ons from the group, plus lists of FAQs and resources 
etc...

This is quite a good format as it''s useful for everyone to see if 
there''s anything good that has been missed.

It does mean keeping track with what''s been going on over the course of
a week, but between a few people suggesting what should go in it 
shouldn''t be too much of a chore.

Something like:

1 - what''s happened this week.
   - new releases, any interesting news all linked to the relevant posts 
on ruby-forum

2 - Resources / FAQs
   - list of places to get ruby/rails help/info

3 - Group Etiquette
   - few lines on posting guidelines - IE what spurned this thread in 
the first place

I''d certainly be willing to help out.

-- 
R.Livsey
http://livsey.org