XML renderings

Piers_C · April 25, 2006, 9:20pm

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?

http://www.loudthinking.com/arc/000572.html

Piers_C · April 25, 2006, 9:33pm

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 reallyis 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. [email protected] 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.
[email protected]> http://www.bofh.org.uk/>
_______________________________________________> Typo-list mailing list>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>

Piers_C · April 26, 2006, 6:59am

“Scott L.” [email protected] 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 reallyis 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_C · April 27, 2006, 5:25am

A couple things:

How do we do both RSS and Atom feeds?
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. [email protected] wrote:> “Scott L.”
[email protected] 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 reallyis 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 [email protected]> http://www.bofh.org.uk/> _______!
________________________________________> Typo-list mailing list>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>

Piers_C · April 27, 2006, 9:25pm

Scott L. wrote:

A couple things:

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

Piers_C · April 27, 2006, 11:33pm

“Scott L.” [email protected] writes:

On 4/27/06, mathew [email protected] 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.

Piers_C · April 27, 2006, 9:52pm

On 4/27/06, mathew [email protected] 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 · April 28, 2006, 12:40am

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 · April 28, 2006, 12:00am

On 4/27/06, Piers C. [email protected] wrote:> “Scott L.”
[email protected] 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

Piers_C · April 28, 2006, 9:05am

mathew [email protected] 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.