Forum: Typo XML renderings...

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Piers C. (Guest)
on 2006-04-25 23:20
(Received via mailing list)
So, on another project, I've been playing with 'respond_to'[1] and it's
*lovely*. I am seriously considering rejigging things so that our
index type pages in articles_controller will all be responsible for
generating rendering feeds and make the xml_controller simply act as a
redirect to the new /articles based urls.

Thoughts?

1. http://www.loudthinking.com/arc/000572.html
Scott L. (Guest)
on 2006-04-25 23:33
(Received via mailing list)
I'm kind of conflicted on this one.  The respond_to code is reallynice,
I'm using it on a little toy that I wrote for work a coupleweeks ago.
On the other hand, I hate changing URLs, and moving feedsis a pain in
the neck.  On the gripping hand, the basic code really*is* the
same--select a bunch on content, and then render it.
So I guess I can say that I can see arguments either way.  Pick
yourfavorite :-).

Scott
On 4/25/06, Piers C. <removed_email_address@domain.invalid> wrote:> So, on 
another
project, I've been playing with 'respond_to'[1] and it's> *lovely*. I am
seriously considering rejigging things so that our> index type pages in
articles_controller will all be responsible for> generating rendering
feeds and make the xml_controller simply act as a> redirect to the new
/articles based urls.>> Thoughts?>> 1.
http://www.loudthinking.com/arc/000572.html>> --> Piers C.
<removed_email_address@domain.invalid>> http://www.bofh.org.uk/>
_______________________________________________> Typo-list mailing list>
removed_email_address@domain.invalid>
http://rubyforge.org/mailman/listinfo/typo-list>
Piers C. (Guest)
on 2006-04-26 08:59
(Received via mailing list)
"Scott L." <removed_email_address@domain.invalid> writes:

> I'm kind of conflicted on this one.  The respond_to code is reallynice, I'm using it on 
a little toy that I wrote for work a coupleweeks ago.  On the other hand, I hate changing 
URLs, and moving feedsis a pain in the neck.  On the gripping hand, the basic code 
really*is* the same--select a bunch on content, and then render it.
> So I guess I can say that I can see arguments either way.  Pick
> yourfavorite :-).

For me, the DRY aspects of this are a huge win. If we can reduce the
XML framework to a simple set of redirects that can be optionally
turned on and off then new typo blogs can simply start up with the new
url scheme, and us old farts can continue to serve up the URLs we've
always served up.

And every time we add a new index, we can just write the appropriate
rxml files and be done.
Scott L. (Guest)
on 2006-04-27 07:25
(Received via mailing list)
A couple things:
1.  How do we do both RSS and Atom feeds?
2.  How does this interact with the Atom publishing protocol?  I'vebeen
dealing with the Google C. protocol lately, and it's moreor less
the same as the Atom publishing protcol.  It's a very nice,RESTful, way
to do things.  But it'd be nice if we could support itwithout having to
fight with the new URL stuff.  Yeah, I know this isa research question
:-(.

Scott
--sooner or later, we're going to want to add Atom API support.  It'sa
very nice protocol
On 4/25/06, Piers C. <removed_email_address@domain.invalid> wrote:> "Scott L."
<removed_email_address@domain.invalid> writes:>> > I'm kind of conflicted on 
this one.  The
respond_to code is reallynice, I'm using it on a little toy that I wrote
for work a coupleweeks ago.  On the other hand, I hate changing URLs,
and moving feedsis a pain in the neck.  On the gripping hand, the basic
code really*is* the same--select a bunch on content, and then render
it.> > So I guess I can say that I can see arguments either way.  Pick>
> yourfavorite :-).>> For me, the DRY aspects of this are a huge win. If
we can reduce the> XML framework to a simple set of redirects that can
be optionally> turned on and off then new typo blogs can simply start up
with the new> url scheme, and us old farts can continue to serve up the
URLs we've> always served up.>> And every time we add a new index, we
can just write the appropriate> rxml files and be done.>> --> Piers
Cawley <removed_email_address@domain.invalid>> http://www.bofh.org.uk/> _______!
________________________________________> Typo-list mailing list>
removed_email_address@domain.invalid>
http://rubyforge.org/mailman/listinfo/typo-list>
mathew (Guest)
on 2006-04-27 23:25
(Received via mailing list)
Scott L. wrote:
> A couple things:
> 1.  How do we do both RSS and Atom feeds?
>

Ruby XML Builder 2.0 was released recently. It now does automatic
escaping. I don't find Atom or RSS to be complicated enough that it's
worth using a special purpose library to *produce* them; they're just
XML, after all.


mathew
Scott L. (Guest)
on 2006-04-27 23:52
(Received via mailing list)
On 4/27/06, mathew <removed_email_address@domain.invalid> wrote:> Scott L. 
wrote:> > A
couple things:> > 1.  How do we do both RSS and Atom feeds?> >>> Ruby
XML Builder 2.0 was released recently. It now does automatic> escaping.
I don't find Atom or RSS to be complicated enough that it's> worth using
a special purpose library to *produce* them; they're just> XML, after
all.
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?

Scott
Piers C. (Guest)
on 2006-04-28 01:33
(Received via mailing list)
"Scott L." <removed_email_address@domain.invalid> writes:

> On 4/27/06, mathew <removed_email_address@domain.invalid> wrote:> Scott L. wrote:> > A
> couple things:> > 1.  How do we do both RSS and Atom feeds?> >>>
> Ruby XML Builder 2.0 was released recently. It now does automatic>
> escaping. I don't find Atom or RSS to be complicated enough that
> it's> worth using a special purpose library to *produce* them;
> they're just> XML, after all.


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

DHH covers this in the article where he introduced them; you munge the
request to have an appropriate Accepts and serve up
'application/xml+rss' and 'application/xml+atom' or whatever it is.

And ideally we drop Atom 0.3 from our supported list.
Scott L. (Guest)
on 2006-04-28 02:00
(Received via mailing list)
On 4/27/06, Piers C. <removed_email_address@domain.invalid> wrote:> "Scott L."
<removed_email_address@domain.invalid> writes:> > 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?>> DHH covers this in the article where he
introduced them; you munge the> request to have an appropriate Accepts
and serve up> 'application/xml+rss' and 'application/xml+atom' or
whatever it is.
I'm having a hard time finding this.  Pointer?
> And ideally we drop Atom 0.3 from our supported list.
No problem, but I'd like to have at least *one* release with both,just
for transition's sake.
Also, using respond_to blows caching out of the water again.  The
pagecache is completely unsuitable for URLs that can feed either Atom
orHTML, and the action cache will need a bit of work.

Scott
mathew (Guest)
on 2006-04-28 02:40
(Received via mailing list)
Scott L. 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.

Personally, I'd make /articles be Atom format, and have something like
/articles?format=rss or /articles/rss for legacy RSS support.


mathew
Piers C. (Guest)
on 2006-04-28 11:05
(Received via mailing list)
mathew <removed_email_address@domain.invalid> writes:

> Scott L. 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,
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 }
    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.
This topic is locked and can not be replied to.