mathew <[EMAIL PROTECTED]> writes:
> Scott Laird wrote:
>> No, I mean if we move the Atom feed from /xml/... to /articles,
>> anddistinguish between the Atom feed and the HTML feed via the Acceptheader,
>> then how do we feed both Atom and RSS from the same URL?
>
> Why do they have to be from the same URL? I must have missed that
> bit.
Here's ArticlesController#index
def index
@pages, @articles =
paginate(:article, :per_page => this_blog.limit_article_display,
:conditions =>
['published = ? and contents.created_at < ? and blog_id = ?',
true, Time.now,
this_blog_id],
:order_by => "contents.created_at DESC",
:include => [:categories, :tags])
end
Which is (with a couple of extra wrinkles, which can be ironed out)
pretty much the same as what /xml/feed does (XmlController is actually
slightly better factored than articles_controller, but it will break
as soon as anyone adds a second blog).
The issue isn't so much to do with serving Atom, RSS, and HTML from
the same URL as it is with serving them from the same controller
action, reducing the amount of duplicated effort in controllers (and
avoiding the current problem where ArticlesController#index is
multiblog safe, but XmlController#fetch_items -- which is what finds
the things to be published -- isn't.
> Personally, I'd make /articles be Atom format, and have something like
> /articles?format=rss or /articles/rss for legacy RSS support.
Definitely the first rather than the second of those options; that way
a prefilter can grab the format variable and use it munge the
headers. Here's ArticlesController#comment, rewritten to to use
respond_to (and, incidentally, so that it'll work with non ajax
commenting again)
def comment
return unless comment_args_are_valid?
begin
@article = this_blog.published_articles.find(params[:id])
@comment =
@article.comments.build(params[:comment].merge({:ip =>
request.remote_ip,
:published => true })
@comment.user = session[:user]
@comment.save!
add_to_cookies(:author, @comment.author)
add_to_cookies(:url, @comment.url)
respond_to |wants| do
wants.js # AJAXy updating
wants.html { display_article @article }
end
rescue
STDERR.puts @comment.errors.inspect
render_error(@comment)
end
end
def comment_args_are_valid?
if ! request.post?
render_error "You can't GET a new comment!"
return
end
unless @request.xhr? || this_blog.sp_allow_non_ajax_comments
render_error("Please turn Javascript on and try again")
return
end
end
Hmm... you know, I really dislike all those 'render_error(...); return'
things. I'm having bad thoughts... how do you think rails would
react to a prefilter that looked like:
def save_the_continuation
callcc do |continuation|
@filter_continuation = continuation
true
end
# This is where @filter_continuation[some_value] will return to.
# By returning false through this continuation, rails is fooled
# into thinking that your filter chain failed (but any rendering
# you did still gets done...)
end
Then, render_error would look like:
def render_error(object = '', status = 500, [EMAIL PROTECTED])
@text = object.errors.full_messages.join(", ") rescue object.to_s
@status = status
respond_to |wants| do
wants.js # For sensible error reporting of AJAX type requests
wants.html { render :text => text, :status => status }
end
# Make the prefilter return false!
return_point[false] unless return_point.nil?
end
I have the sneaking feeling that that would work rather well... I
shall experiment when I have the tuits.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
_______________________________________________
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
