This browser_cache method doesn't look to offer much more
than what can already be done via expires_in; which requires
a bit more knowledge of Cache-Control. There's got to be
an easier way. What about something like:
class WeblogController < RestController
verbs_for :index do
cache_resource :person, :as => :public, :for =>
10.minutes, :only => :get
def get
@person = Person.new(params[:id])
end
end
end
The cache_resource method could look at whatever object is
within @person and inspect its updated_at/lock_version
attributes to set the outgoing Last-Modified and ETag headers.
It could also set the Cache-Control and Expires headers.
Of course, with the :only => :get command we'd restrict this
to happening only for GET requests.
You're right, browser_cache is too far removed from the action.
However, I'm not entirely comfortable with cache_resource referencing
a instance variable that'll appear in the method using just a symbol.
It feel like cause and effect is a tad too separated.
But more importantly, I reckon that lots of pages won't rely simply
on a single resource to compute whether they're stale or not. At
least that's not the use model I've been finding to be true.
So perhaps your first inclination was right.
class WeblogController < RestController
verbs_for :index do
def get
@person = Person.new(params[:id])
render :modified_at => @person.updated_at
end
end
end
This would by default just produce a :etag based on the :modified_at,
but you would also be allowed to set that explicitly ala:
render :modified_at => @person.updated_at, :etag =>
@person.lock_version
Because then we could use better composite models ala:
class WeblogController < RestController
verbs_for :index do
def get
@posts = Post.find(:all, :order => "updated_at")
@comments = Comments.find(:all, :order => "updated_at")
render :modified_at =>
@posts.first.updated_at > @comments.first.updated_at ?
@posts.first.updated_at : @comments.first.updated_at
end
end
end
Or something less contrived, but you get the drift. Lots of pages are
not bound to merely 1 model. Being a little more explicit opens it up
to wider usage, me thinks.
Incidentally, I've implemented a working Rails controller
that inherits from ActionController::Base that uses the
"verbs_for" syntax you mentioned at the beginning of
Round 2. It handles true conditional GET requests and
OPTIONS methods. Conditional PUT works too, which
allows a web service/AJAX client to get around the whole
"stale update" problem.
Awesome. Can't wait to see that!
--
David Heinemeier Hansson
http://www.37signals.com -- Basecamp, Backpack, Writeboard, Tada
http://www.loudthinking.com -- Broadcasting Brain
http://www.rubyonrails.com -- Web-application framework
_______________________________________________
microformats-rest mailing list
[EMAIL PROTECTED]
http://microformats.org/mailman/listinfo/microformats-rest
