Fresh_when/stale? usage

In my post_index action, I generate different kinds of “@posts” like…

def index
case params[:listing_type]
when “all”
@posts = get_all_post_from_memcached
when “most_popular”
@posts = get_all_most_popular_from_memcached

      respond_to do |format|
           format.html
           format.js #for ajax reqeusts
           format.xml #for rss etc

end

From what I understand fresh_when takes a etag, and it is to be used
if there is no difference in different kinds of rendered (in my case
the rendering is different based on html or ajax)

and

stale? also takes an etag and surrounds the respond_to block.

In this case the etag will be different based on the different listing
types. But it seems there isn’t much flexibility in the way fresh_when
or stale? can be used here?

Thanks

##updated

    def index
         case params[:listing_type]
              when "all"
                    #the key here is teh same key I used for

memcached
if stale?(:etag => ‘all_posts_key’)
@posts = get_all_post_from_memcached
else
head :not_modified and return
end
when “most_popular”
if stale?(:etag => ‘most_popular_key’)
@posts = get_all_most_popular_from_memcached
else
head :notified and return
end
respond_to do |format|
format.html
format.js #for ajax reqeusts
format.xml #for rss etc
end

update. I changed the original block a little and now get a double
render error what am I doing wrong, should “head :notified and return”
just return the header and not touch the respond_to block?

The stale & fresh blocks already will send not modified back to the
client. Since you are also sending it, you get a double render.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs