Tom, in cms you can set the default content type to "no_content"
which then does not provide the content upload/entry fields
(although it does still ask for mime type but that is just an easily fixed bug). It then acts more like what you are
talking about.
For things like images where you don't usually want to version
the large binary object but probably do want versioning on the other attribute data you create two content types one of image with minimal data (in the case of the image type provided in CR, width and height) and a second content type with all the other attributes you want to maintain and then just relate the two objects.
CMS will actually create the columns and views for the content type for you given the attribute metadata, has code to generate the creation and editing forms, handles doing inserts and updates of content, has provisions for storing an XML version of each revision, lets you associate a template with a content type, lets you relate
content items fairly easily, and will write rendered content
to the filesystem. It does not all work flawlessly but an
awful lot of it is quite close to working and would work correctly with a little more attention. There really isn't
anything built into the CR or CMS to prevent you from
having pure "content" and avoiding big hunks of html as the
content.
Well, the only real roadblock is that the UI of CMS is beyond trainwrecklike. But the backing code
really does a lot of smart things for managing structured
data. Where it does less well is for composite objects where you would want to edit a parent and n children (e.g. a wp slide where you would want to edit the slide and the bullet points and have the slide and each bullet point be a
cr_item) but I am doing some work that will make that
possible as well.
Anyway, I would strongly recommend anyone contemplating
creating yet another CMS take a look at what the current
cms can do and consider how much easier it would be to fix the UI for the existing system than to create a new one from
scratch.
