Maybe I need to dump my assumptions for a moment. Knowing the page that we're about to be rendering from the cache would be a useful thing. Why can't we do it? Because the performance of Page.find_by_url sucks.
I talked a little bit about that suckage a while ago, and somebody (Adam? Sean?) suggested having a table to directly find lookup a page from it's url from the database. I was originally dismissive, but the idea is starting to grow on me. - Create a page_urls table - Whenever the slug or type of a page changes, that page and all of its children (recursively) would update the page_urls table with their current url(s). If a page isn't found using a direct lookup, a regular Page.find_by_url call would be made, so that we can still maintain all the flexibility that provides. Advantages of this system are: - faster to lookup pages by url (though I don't know if it will be fast enough that I'd want it before the cache check) - all children of a page could be discovered recursively through: PageUrl.find(:all, :include => :page, :conditions => 'url like ?', "#{parent_url}%") - old urls could be left in the table - automatically giving 'cool urls' - unless another page comes to replace it or the page is no longer published, a page is always available through it's old address. Old urls would probably get a marker and redirect to the real urls of a page. Disadvantages: - Database isn't third normal form (the url is a calculated field, not raw data), makes my inner database purist feel queasy. - Long save times when slug/type changes I should probably do some other things instead, but I might have a look at this. Dan. _______________________________________________ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant