Ruby Forum Radiant CMS > Layouts, snippets and site assets on the file system?

First off, what I have done so far in Radiant has been pretty inspiring.
I usually hate CMS solutions due to their inflexibility.  The super
simple Radiant extension is a huge selling point for me.  I intend to
use a Radiant install as the base for projects since it gives me
publishing, admin authentication, and admin architecture for almost no
effort.  I'm pretty experienced with Rails, but new to Radiant.

Maintaining layouts and snippets in the admin interface via text area is
so much less fun than editing these things in Textmate.  My current
workflow is to use the "It's all text" Firefox plugin to edit text area
contents in Textmate.  It's not so bad, but I have switch to the browser
and press the save button, then switch to my tab with the radiant app
and refresh to see my changes.  Its far more tedious than the usual
cmd-s, cmd-tab, F5 I'm used to.  Page content would change far more
frequently and is a good fit for the database, in my opinion.  Plus the
regular, non-technical, maintainers of the site probably shouldn't have
access to changing layouts and snippets anyway.

So, I am looking for a way to store site structure files in the file
system, version controlled and in a higher level template language like
erb or haml.  Then store page content in the database in radius format
just like normal.

Is there an extension for that?  Or is that even a good idea?

Thanks for the great tool,
-Alex

Alex,

I've been promising for a long time, so I better own up on it.  I wrote
an extension for Digital Pulp that lets you import/export several models
between the database and the file system so that they can be stored in a
SCM.  There are a number of other extensions that the DP devs and I have
been wanting to export for a while.  Although I have a few other things
to do this Friday, I'll put that on the to-dos as well.

Sean

Sean Cribbs wrote:
> Alex,
> 
> I've been promising for a long time, so I better own up on it.  I wrote
> an extension for Digital Pulp that lets you import/export several models
> between the database and the file system so that they can be stored in a
> SCM.  There are a number of other extensions that the DP devs and I have
> been wanting to export for a while.  Although I have a few other things
> to do this Friday, I'll put that on the to-dos as well.
> 
> Sean

Rock on.  Thank you, I will keep an ear out!

Sean Cribbs wrote:
> Alex,
> 
> I've been promising for a long time, so I better own up on it.  I wrote
> an extension for Digital Pulp that lets you import/export several models
> between the database and the file system so that they can be stored in a
> SCM.  There are a number of other extensions that the DP devs and I have
> been wanting to export for a while.  Although I have a few other things
> to do this Friday, I'll put that on the to-dos as well.
> 
> Sean

Firstly, I realize I am in no position to demand anything!

I have been watching the git repo and the blog, and haven't seen 
anything about this.  Any progress that i missed?

Thanks.

In parallel, it would be nice to add another basic user-level of 
"Designer", for managing Snippets - in the absence of SCM/file support 
for layouts/partials.

In keeping designs and code DRY, we find ourselves using snippets to 
contain more than user-editable content, and use them heavily for 
fragments of design logic. As such, we want to keep day-to-day users far 
away from anything that can cause damage to the site.

Standard (Pages) -> Designer (+ Snippets) -> Administrator (+ Layouts, 
Users, etc)

Does the Developer flag do anything in production mode?

Thanks,
Jon.

Sean Cribbs wrote:
> Alex,
> 
> I've been promising for a long time, so I better own up on it.  I wrote
> an extension for Digital Pulp that lets you import/export several models
> between the database and the file system so that they can be stored in a
> SCM.  There are a number of other extensions that the DP devs and I have
> been wanting to export for a while.  Although I have a few other things
> to do this Friday, I'll put that on the to-dos as well.
> 
> Sean

Was this done via FUSE?

http://redhanded.hobix.com/inspect/railsfsAfterACoupleMinutesOfToolingWithFuseWhoa.html

Seems like that's the "Right" way. I've used FUSE extensively to mount 
remote filesystems via SSH and it works wonderfully.

--DJCP

Daniel Collis-puro wrote:

> Was this done via FUSE?
> 
> http://redhanded.hobix.com/inspect/railsfsAfterACoupleMinutesOfToolingWithFuseWhoa.html
> 
> Seems like that's the "Right" way. I've used FUSE extensively to mount 
> remote filesystems via SSH and it works wonderfully.
> 
> --DJCP

Highly unlikely. FUSE is a modular file system API - basically a simple 
means to build your own file system without actually having to do 
anything majorly complex. Although yes, what you linked to would be a 
cool solution - it still lacks version control. You'd also have to make 
it uber-bespoke to Radiant, and to each model in the Radiant schema, 
otherwise you'll be working with YAML etc. If somebody did build a FUSE 
interface for Radiant, it would be nice if each page is represented by a 
folder, with files corresponding to each page part, with the extension 
being the filter used. A meta file could contain the overall page 
settings.

eg:

/welcome/ (path is slug)
/welcome/page.meta (YAML settings for page)
/welcome/body.textile
/welcome/extended.smartypants
/welcome/extended.html (plain/non-filtered)

and so forth...

The real goal here however, is to allow layouts and partials to exist in 
the filesystem (within the 'app/view' folder structure), which 
immediately allows you to use an SCM (SVN, CVS, GIT etc) either for the 
whole project, or as an SVN External (or GIT/CVS equivalent). My 
preference would be to allow both file system and DB based 
layouts/snippets to co-exist, with file system layouts taking precedence 
in case of name clashes. It'd be great to use HAML as well. I'd also 
add, support for Multi-Site would be highly desired.

Jon.

Jonathan McCoy wrote:
> settings.
>   
You just described the file_system extension written for Redken to a T.
I would like to release it but I'm not ready to support it yet or to
detox the code.

Sean

Gah! Shafted again! How long you gonna keep these awesome extensions 
under your wings? What detoxing needs to be done?

Sean Cribbs wrote:
> Jonathan McCoy wrote:
>> settings.
>>   
> You just described the file_system extension written for Redken to a T.
> I would like to release it but I'm not ready to support it yet or to
> detox the code.
> 
> Sean

Sean Cribbs wrote:
> Jonathan McCoy wrote:
>> settings.
>>   
> You just described the file_system extension written for Redken to a T.
> I would like to release it but I'm not ready to support it yet or to
> detox the code.
> 
> Sean

Nice!

My next mission is to design/build a platform for content delivery (the 
binary kind) - basically a front end for managing content (videos, 
images, PDF's etc), engines to maintain and distribute the content 
(faux-RAID), and a delivery mechanism (caching HTTP app). Keen to find a 
solution using Radiant, but failing that will build a plugin for the 
integration.

Jon.

Jonathan McCoy wrote:
> In parallel, it would be nice to add another basic user-level of 
> "Designer", for managing Snippets - in the absence of SCM/file support 
> for layouts/partials.
> 
> In keeping designs and code DRY, we find ourselves using snippets to 
> contain more than user-editable content, and use them heavily for 
> fragments of design logic. As such, we want to keep day-to-day users far 
> away from anything that can cause damage to the site.
> 
> Standard (Pages) -> Designer (+ Snippets) -> Administrator (+ Layouts, 
> Users, etc)
> 
> Does the Developer flag do anything in production mode?
> 
> Thanks,
> Jon.

I've monkey-patched a frozen version of Radiant (0.6.7) with some of the 
functionality I lusted for above. No testing or a "designer" flag (just 
put snippets on the Admin/Dev level). I'd be more inclined to assemble 
patches and tests (to the spec above) if anybody else was interested in 
it being pushed into the trunk?

Would be nice to review the user levels available - or if we're all 
feeling code-happy, granular access control. I can foresee the need for 
the following roles at least:

1. Content Monkey (pages + preferences)
2. Designer (+ layouts + snippets)
3. Developer (+ extensions)
4. Administrator (+ user management)

In hindsight to my previous post, I'd keep the developer flag for the 
benefit of extensions/plugins that need technical setup. Another 
question, is whether flags are more desirable than a user-level number 
(ie 1 to 4) or even a class-name, which can be mapped out to a role 
name. A popup list with userlevels can be used instead. It removes the 
uncertainty of having admin flagged, but developer unflagged -> what 
rights does the user have?!

I am having trouble finding where the user-level is set for the tab 
display - I've traced back through all the libraries, but can't seem to 
find (or rather see) where snippets (or rather other admin/dev tabs) are 
set...

Cheers,
Jon.

On 14 Jun 2008, at 18:51, Sean Cribbs wrote:

>> to each page part, with the extension being the filter used. A meta  
>> file could contain the overall page settings.
>>
> You just described the file_system extension written for Redken to a  
> T.  I would like to release it but I'm not ready to support it yet  
> or to detox the code.

I asked Sean if I could have a go at detoxing his code myself. I've
stripped out all of the Redken specific functionality, and got the
extension working on a vanilla Radiant site (i.e. with no other
extensions). Here it is:

  http://github.com/nelstrom/radiant-file-system-extension/tree/master

I'd be happy to hear any feedback.

Cheers,
Drew

Nice work, Andrew. I wonder how hard it would to get this extension to
also dump and load SnS text assets. Not that any of the extensions
should have a dependency on the other, but the file-system-extension
could perhaps check for the presence of SnS and dump that too, if
present?

Cheers,
Casper

When I designed the extension, I toyed with the idea of providing a way
for extensions to specify how to dump/load their own models.  IIRC, you
can just create an appropriately named module and then add the model to
the constant array in the FileSystem module.  You should probably do all
of that in your extension file.

Sean

Nice - thanks, Sean