[Grok-dev] Re: maintaining the Grok website

[Martin Aspeli]

Brandon Craig Rhodes wrote:
> Martin Aspeli <optilude at gmx.net> writes:
> 
>> If I'm allowed to be a little blunt ... You need a CMS.  That CMS
>> should be Plone.
> 
> I would like for the website to remain editable through Subversion.

Very few websites are maintained this way, for good reason. ;-)

> Having to edit content through-the-web has all of the same drawbacks
> as having to write code through one's web browser.  

I don't think that's true at all. Code and content are different types 
of things. You don't need to branch, blame and merge content.

> Just like we now
> do filesystem-based development, rather than attempting to edit and
> maintain "Script" objects inside an application, so we also ought to
> preserve our ability to access and version-control our content

Plone makes access and versioning (including staging, where you edit a 
working copy of a published item) trivial.

> through
> the same strong tools that manage our source code.

The problem with using something like svn is that you invariably divorce 
the text from the actual in-situ content. You are editing something 
abstract and then generating the output separately.

> I also like the fact that someone can, with a single command, check
> out the raw ReST files from Subversion and have quite readable text
> documentation on their filesystem.

reST is fine for doctests and tutorials, but not terribly expressive. A 
good website is not top-to-bottom text, it is about layout and structure.

reST also gives you next to no help when it comes to linking it all 
together, moving things around, generating navigation and so on.

> Can a Plone site - or at least part of it - be back-ended through
> Subversion, or accessed through Subversion using DAV or something?

In theory you could devise a storage that used SVN for some text, but I 
see little-to-no actual need for this when Plone already has versioning 
tools that are more appropriate for content.

The most important thing here needs to be the ease with which you can 
produce something for your end users and authorship. CMS' such as Plone 
were developed to make it easier to publish information in a format 
that's "reader friendly", and make it easier to collaborate on content 
and manage content that is in various states through workflow, worklists 
and so on.

An svn backing for Plone has little use: All the versioning support you 
need is already in the CMS, and is more accessible to possible 
contributors that way. If you want to have have "plain" reST that's 
generated into HTML, then that's what Grok has now, and as Martijn is 
pointing out, this introduces a bottleneck.

Martin

-- 
Acquisition is a jealous mistress