Forum OpenACS Development: Re: Idea: New Content Paradigm

Collapse
7: Re: Idea: New Content Paradigm (response to 1)
Posted by Tom Jackson on 02/22/03 09:22 PM
Can you elaborate a bit? This is interesting.

Sorry, Ola, I was posting at the same time as you.

Don't get me wrong, I am warming up to the CR. I just don't have one big chunk of content per item, so I'm wondering if it is going to work. Also I am wondering what to do about video and images. Although these are content, the hardly need editing, it is more likely that the attributes would be edited than the main content item.

Anyway, with structured data, would it be possible to create a web page that allowed you to edit the individual items instead of entering the markup directly? If there were a schema for the item, maybe you could have controls for adding chunks of information.

If you know how to write the structured markup, you could still add it in-line and on the next update the form would change to allow further editing. I don't know how useful that would be, but a single textarea box to edit a huge document is almost useless.

Collapse
8: Re: Idea: New Content Paradigm (response to 7)
Posted by Jeff Davis on 02/22/03 11:36 PM
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.