Yesterday I committed a new core extension to Radiant: Sheets
config.extensions -= [:sheets]
What is Sheets?
Pages of these types are Sheets.
The basic features:
- set a longer expire time for Sheet content with
sheet_cache_timeout(similar to the typical
cache_timeoutset for pages)
- provide Radius tags to output content as it is, as a link to content, and as an HTML element containing the content
- append a timestamp to sheet content URLs so that the cache need not be cleared with the same frequency for updates to typical pages
Differences with other solutions and the benefit of using Sheets
Some standard site templates provided by Radiant include stylesheet content in a typical page. This requires a custom layout merely to set the content type, and displays content unintended for editing by typical users. This makes for a cluttered page index view and cluttered layout index view.
You can get around this SNS limitation by using the SNS Page Hook extension but even this solution will lead to unpredictable results because it merely copies modules from the Page model to the TextAsset model and tricks the included methods into believing they are operating on a Page. But this is not a good long-term solution.
Not only does it do all this, but the standard Page model provides a
headers method which Sheets overrides to alter the mime-type for the returned content. Sheets uses the built-in ways to serve content, rather than generating yet another way to serve content like SNS.
By default Sheets has a SassFilter for text and since Radiant depends on (and includes) Sass, you’ll always have that available. But the SassFilter is just a regular TextFilter like the ones used on pages so I had to do some work to ensure that you wouldn’t be able to filter your typical Page content with Sass.
The SheetsExtension has 2 accessors:
You may manipulate the contents of these variables with your added text filters. You could write an extension to provide a Less filter:
SheetsExtension.stylesheet_filters << LessFilter
In the future, it will probably be a good idea to move these accessors off of the SheetsExtension itself and onto the ApplicationController so that you don’t need to worry about extension load order to add a text filter.
Currently, there is no interface element to alter the path from where your site will pull content. CSS is pulled from
/js. SNS was standardizing this approach because changing this setting required running rake tasks and not merely changing a simple setting. With Sheets, the path is determined by a page slug so in the future we’ll have a way to change that location to
/whatever-you-want (but if you really want to do it now just jump in the console find the
js pages and change their slugs).
I will be providing the ability to migrate your content from SNS to the page tree in some way (be it in the Sheets extension itself, in SNS, or some other migrator extension).
I still need to write some specs and cucumber features but I wanted to get this out in the wild to get feedback, so please leave your complaints or praise here.
Reasons for the change from SNS
Aside from the reasons I’ve listed above I could only see more difficulty down the road in getting TextAssets to behave the way you’d expect. I’ve been committing a lot of changes to SNS and recently wrote the SNS Page Hook extension to deal with these problems.
If you’re a user of SNS, I really think you’ll like the change to Sheets.