Ruby Forum Radiant CMS > Possible to disable cache for a single page?

Hi,

I have a list of thumbnails and when clicked they open a larger image in
a popup window.

I have a page in radiant with a <r:press_image /> tag for the popup and
supply an img-parameter to the page that I use in the tag that looks
like this:

tag 'press_image' do |tag|
  html = ""
  img = tag.globals.page.request.parameters[:img].nil? ? nil :
tag.globals.page.request.parameters[:img].to_i
  item = PressAttachment.find(img) if img
  html = '<a href="#" onclick="window.close();"><img src="' +
item.public_filename(:full) + '" alt="" /></a>' if item
  html
end

Works fine on my machine where cache is disabled but on the live server
the popup is cached and it always displays the first image viewed
because of the cache.

My question is if I can disable the cache for a single page or if anyone
has a suggestion to how I could achive this otherwise.

Thanks in advance, love working with radiant and my clients too :)

I'm doing some similar and would love to know how to achieve this!

The typical solution is to make a page subclass that adds this method:

def cache?
  false
end

Then make the page that you want uncached to be of that type.  Before
you do that, however, take into consideration why you need the page
uncached.  It may be that the need for it to be uncached is secondary
to a greater functional need from the system, and that that should be
addressed first.

Sean

Hi Sean

Sean Cribbs wrote:
> The typical solution is to make a page subclass that adds this method:
>
> def cache?
>   false
> end
>   

I'm just thinking of putting this down as the starting point for one of
the pages in the 'Summer Reboot' but I have a couple of questions to
understand this slightly better:
1. Where would that code go?  How does one go about creating a page
subclass - from there on, it's easy.

> Then make the page that you want uncached to be of that type.  Before
> you do that, however, take into consideration why you need the page
> uncached.  It may be that the need for it to be uncached is secondary
> to a greater functional need from the system, and that that should be
> addressed first.
>   

2. What would be an example of a greater functional need from the 
system?

I'm guessing comments fields and some other dynamic pages would need
this functionality.  What should someone be careful of in disabling the
cache for a page?

Thanks
Mohit.

Hi Sean,

thank you for your answer, works perfectly. I made a no_cache_page.rb in 
my models folder for my extension and put this in it:

class NoCachePage < Page
  def cache?
    false
  end
end

To activate it I just put NoCachePage in the activate method of my 
extension.

Btw. a possible subject for the Summer Reboot could be explaining the 
different ways you include your extension files in the activate method, 
right now I have a mix that I have found in different extensions looking 
like this:

NoCachePage
Page.send :include, CollectionTags
Page.send :include, PressTags

The NoCachePage thing I found in the MailerExtension while the Page.send 
examples are from the PageAttachments extension, but now I see that the 
MailerExtension's tags are included without using Page.send. Is there 
anything already written on this subject?

Thanks again for making the most enjoyable cms around and the nice 
support here.

Gert Jørgensen wrote:
> examples are from the PageAttachments extension, but now I see that the 
> MailerExtension's tags are included without using Page.send. Is there 
> anything already written on this subject?
>
>   
Hi Gert

There are currently seven articles listed (planned? hoped for?) under
the Summer Reboot:

3. Writing your Own Extension
    * Creating an extension I – Adding tags (and some useful tags) [AW]
    * Creating an extension II – Adding a tab in Admin UI (and what is
shards?)
    * Creating an extension III – Modifying the Page UI from an 
extension
    * Creating an extension IV – Extending and overriding Radiant
behavior [CF]
    * Creating an extension V – Creating a special page type
    * Creating an extension VI – Skinning controllers with front-end
layouts (share_layouts) [SC]
    * Global Tags

I think a part of what you wrote here belong in Part V.  As for what
happens upon activation and how tags could be included, we need
something.  Perhaps, something like 'Inside an Extension' that explains
some of the concepts involved in an extension?

By the way, please feel free to add any information to the Summer Reboot
- don't worry about it being complete/ completely correct.  It will get
fixed eventually!  Also, since it's a wiki, some information is better
than no information - the first run is for developers.. and the 'Summer
Reboot' equivalent of "Citation Needed" is most acceptable.  Just start
something (oops, I sound like a Microsoft[1] or Sony[2] campaign!)

Cheers,
Mohit.
8/5/2008 | 11:14 PM.

[1]
http://www.microsoft.com/presspass/press/2005/Apr05/04-18StartSomethingPR.mspx
[2] No link, but it was a campaign that Sony ran with a music TV 
channel!

> I'm just thinking of putting this down as the starting point for one of the
> pages in the 'Summer Reboot' but I have a couple of questions to understand
> this slightly better:
> 1. Where would that code go?  How does one go about creating a page subclass
> - from there on, it's easy.

That would go in app/models of an extension, preferably.

>
> 2. What would be an example of a greater functional need from the system?
>
> I'm guessing comments fields and some other dynamic pages would need this
> functionality.  What should someone be careful of in disabling the cache for
> a page?

Right.  The only caveat of disabling the cache is the potential for
lower performance.  However, my point in bringing that up is that one
should focus on the _why_ you need an uncached page in the first
place, and address that need first.  For example, with comments (see
the radiant-comments project on github from ntalbott and
artofmission), it may not be necessary to make the page uncached
because you can clear the cache after a comment is posted.

Sean

Sean Cribbs wrote:
> Right.  The only caveat of disabling the cache is the potential for
> lower performance.  However, my point in bringing that up is that one
> should focus on the _why_ you need an uncached page in the first
> place, and address that need first.  For example, with comments (see
> the radiant-comments project on github from ntalbott and
> artofmission), it may not be necessary to make the page uncached
> because you can clear the cache after a comment is posted.
>   

Sean

Thanks for the explanations.  I shall try to put these into the
documentation this weekend.  I think the example from the
radiant-comments extension will be very useful.  I shall look it up!

Cheers,
Mohit.
8/6/2008 | 12:37 AM.