[Radiant] Why do we have snippets, page-parts and layouts at all?

2007-02-01 Thread Laszlo Varga
First, I'd like to say that I am very happy with Radiant as is. It could be a little simpler than as it is now. I belive that we can delete from the source add a little, drop some models and tables and have more functionality. Pages can have parts and children. Why both? Parts can contain text an

Re: [Radiant] Ideas for reimplementation of radiant caching

2007-02-01 Thread Laszlo Varga
Regarding to caching, I might just try the following: 1. Make the page-parts accessible via urls. ( /pagename/partname ) 2. Make the snippets accessible via urls.( /snippet/snippetname ... might clash ) 3. Have a method on PagePart which'll determine if their rendered context is dynamic or not.

Re: [Radiant] Access to request object from within tags (answer?)

2007-02-01 Thread Laszlo Varga
Daniel! Thanks for trying to help. I must admit my ruby-kungfu is weak. Your suggestion on letting the tag know about the request seems to be right, but when I did what you suggested: require "app/models/page_context" class PageContext alias initialize_before_reformhaz initialize def init

Re: [Radiant] Ideas for reimplementation of radiant caching

2007-01-30 Thread Laszlo Varga
Radiant currently caches only the page urls, without the params after the ? Am I the only one who thinks this is bad? For example my products page listing works by /products?offset=1200&limit=10 and I must turn off caching to make this work. Why not just let the cache work on the full uri? Peopl

Re: [Radiant] Access to request object from within tags (answer?)

2007-01-30 Thread Laszlo Varga
Kaleb Walton wrote: > I'm quite unfamiliar with Mental and only recently started working > with Radiant - I'll look into Mental to see if it meets my needs. > Thanks! Hi I'm fighting this too on Mental. My problem is that included pages (via r:find) have no access to the request. This is because