[Zope-CMF] Re: FSDocument type

[Tres Seaver]

Jens Vagelpohl wrote:
>>> 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.

I don't recall that it did that;  I thought it only did STX rendering.

>> 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).

Static HTML should be an option, too (some people have huge piles of 
that lying around).

> 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.

I think that the directory view bit is a logical extension of your idea: 
  instead of having to create individual FSDocument instances, create an 
FSDirectoryView which points to the content directory, and have *it* 
instantiate the FSDocument objects for you.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com