Forum: Radiant CMS Idea: implementing a MacFuse filesystem for editing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A12a0d13cd04f0fdfe64862a27a32627?d=identicon&s=25 Tobias Fors (Guest)
on 2007-05-26 11:26
(Received via mailing list)
Hi all,

I've recently started a stealthy little project to try and move my
company's web site over to Radiant. Yesterday, while editing, it
struck me how cool it would be to have a MacFuse file system interface
for editing pages in Radiant.

Has anyone else considered this, or even attempted an implementation?
I don't have the skills (yet...) to implement it myself, but darn it
would be nice. I think - haven't really thought that much about it.

All the best
Tobias

--
Tobias: http://www.tobiasfors.se
Citerus: http://www.citerus.se
PNEHM!: http://pnehm.citerus.se/
767bedcbd5dd54d874a602925d98182e?d=identicon&s=25 Oliver Baltzer (Guest)
on 2007-05-27 00:42
(Received via mailing list)
Tobias Fors wrote:
> I've recently started a stealthy little project to try and move my
> company's web site over to Radiant. Yesterday, while editing, it
> struck me how cool it would be to have a MacFuse file system interface
> for editing pages in Radiant.
>
> Has anyone else considered this, or even attempted an implementation?
> I don't have the skills (yet...) to implement it myself, but darn it
> would be nice. I think - haven't really thought that much about it.

I have thought about it, but rather doing something very platform
dependent like (Mac)FUSE, I was considering an abstraction via WebDAV.
It should be fairly straight forward, especially with Rails's CRUD
support. Unfortunately I have not got around doing it yet. WebDAV is
probably the most flexible way of doing it as it is standardized, many
file system browsers already provide hooks for it and you can mount it
via FUSE.

Let me know what you think.

Cheers,
Oliver
A12a0d13cd04f0fdfe64862a27a32627?d=identicon&s=25 Tobias Fors (Guest)
on 2007-05-27 08:53
(Received via mailing list)
Oliver:

I haven't really used WebDAV-tools, so can't say much about it myself,
but it sounds interesting, especially if support is wide. File system
based editing from both Windows/Mac/Linux would be sweet.

Do you have any ideas on how best to handle things like the "slug",
publish status, chosen filter, behavior etc?

/T

2007/5/27, Oliver Baltzer <oliver.baltzer@nobits.com>:
> I have thought about it, but rather doing something very platform
> Oliver
>
>
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
>


--
Tobias: http://www.tobiasfors.se
Citerus: http://www.citerus.se
PNEHM!: http://pnehm.citerus.se/
767bedcbd5dd54d874a602925d98182e?d=identicon&s=25 Oliver Baltzer (Guest)
on 2007-05-27 17:02
(Received via mailing list)
Tobias Fors wrote:
> I haven't really used WebDAV-tools, so can't say much about it myself,
> but it sounds interesting, especially if support is wide. File system
> based editing from both Windows/Mac/Linux would be sweet.
>
> Do you have any ideas on how best to handle things like the "slug",
> publish status, chosen filter, behavior etc?

Hi Tobias,

looking at other CMSs they typically try to wrap as much of the
metadata into the metadata fields provided by the document, e.g. HTML
metatags. This may not work well with Radiant because of its special
document structure consisting of parts. However, one could always use
YAML or a similar text-based format as a page's file representation.
For example:

# behavior:Page
# status:draft
# title:Test Page

# part:body
# filter:textile

h1. Part with Textile content

# part:extended
# filter:

<p>Part with raw HTML</p>

The slug could just be represented by the filename.

This model, however, does not directly support pages that have
children, i.e. act like directories. To support this each page may be
represented as a directory containing a file "index" or "content" that
reflects the content and metadata of the page.

Alternatively, a page's content and properties can represented as a
set of files within the directory. Example:

homepage/
   +- @status
   +- @behavior
   +- @title
   +- @part.body
   +- @part.extended
   +- child1
   |     +- @status
   |     +- @behavior
   |      ...
   +- child2
         +- @status
         ...

Eventually some of the properties may be combined into a single file
called @metadata or similar.

Those are just some preliminary thoughts which hopefully will generate
more ideas. I personally favor the first approach as it allows easier
support of other document types such as images or PDF files.

Let me know what you think.

Oliver
This topic is locked and can not be replied to.