[Zope-CMF] Re: FSDocument type

[Jens Vagelpohl]

>> I want to convert an existing site that uses pretty much static 
>> content (in this case good old DTMLDocuments) to CMF. I want that 
>> content to end up on the file system in skins to improve 
>> maintainability. The most logical content type to use is the CMF 
>> Document. Now, there is no filesystem equivalent so I'm currently 
>> stitching one together.
>> Question: I'd prefer this to go into CMFDefaul rather than stay a 
>> separate thing. Any concerns or comments (or yay/nays)?
>
> We already have an FSSTXDocument type, added as a way to configure 
> "help" pages as skins.  I would be glad to have that class generalized 
> / extended to support static HTML.

That's the thing called "FSSTXMethod". It's crippled in some ways and 
in other ways seems to try and use DTML for rendering. That's why I 
didn't even look at it.


> Yuppie's notion of a "content-space" DirectoryView has merit, as well. 
> Such an object might need some UI for setting policies separately from 
> those of the "software" type.

So let's all elaborate on this a little bit. I don't mind spending some 
time on it, but I want to make sure I have something that is acceptable 
to the de-facto CMF leaders.

The use case, as mentioned before, is the ability to store CMF content 
(in this case only Documents) on the file system. Mainly because they 
are pretty static, but also because I want to be able to use CVS and 
grep and vim easily. I could make them all into FSPageTemplates, but 
that's truly mixing content and code in a nasty way. Besides, I don't 
want them to contain any markup, just simple structured or maybe even 
restructured text (some docs contain images).

I'm not clear what's meant with "content-space DirectoryView". My 
current code is a new CMF type, FSDocument, that plays within the 
standard CMF types rules (type information etc) but it's stored on the 
file system, always "published", and you cannot edit it or its metadata 
TTW.

Let's hear some other ideas!

jens