[typo] XML renderings...

Piers Cawley pdcawley at bofh.org.uk
Fri Apr 28 03:02:20 EDT 2006

mathew <meta at pobox.com> 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])

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?
      @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]
      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 }
      STDERR.puts @comment.errors.inspect

  def comment_args_are_valid?
    if ! request.post?
      render_error "You can't GET a new comment!"
    unless @request.xhr? || this_blog.sp_allow_non_ajax_comments
      render_error("Please turn Javascript on and try again")

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
    # 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...)

Then, render_error would look like:

  def render_error(object = '', status = 500, return_point=@filter_continuation)
    @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 }
    # Make the prefilter return false!
    return_point[false] unless return_point.nil? 

I have the sneaking feeling that that would work rather well... I
shall experiment when I have the tuits.

Piers Cawley <pdcawley at bofh.org.uk>

More information about the Typo-list mailing list