Forum OpenACS Development: Re: Idea: New Content Paradigm

I have been pretty away from the community, been very busy.  So apologies if I blurb some that is unrelated.

Regarding the versioning of CR.  The recommended way to extend it through cr_revisions and not under cr_items.  This would mean as pointed out by Tom.  On big images you will have 2 big copies of images even you just edit the title.  Still if you use the file system to store binay files there is nothing stopping you pointing 2 revision to the same file.  But then of course that will be breaking the rules of the data model design.  But its still possible.  Also its still possible to inherit from cr_items, much like cr_folders did it.  But then the revision procs may not run properly.  As you may need to make some of your own revision procs.  Although a good number is still reusable, surely the insert on a view will not work anymore.

I think the current design of CR is pretty good.  Although CCM makes use of another type of versioning.  It groups attributes to be versioned.  On some cases it simpler, on other cases not.  So for example the title of an image actually points to another table that holds different versions of the title.  Still OACS and CCM CR/CMS data model as no clear advantage over the other.  Look at this post, pretty interesting.  Also shows how ACS 3.x used to do versioning (I think 3.x e-commerce used that type of versioning)

https://listman.redhat.com/pipermail/redhat-ccm-list/2003-February/000791.html

Regarding storing things into XML.  I think it would still be best to create a content type with additional columns store the information rather than storing them as content.  Although not as sexy as it sounds, its relatively very easy to make XML for a bunch of columns.  So yes Talli you can create RSS or pretty much anything from CR.  Also it will be harder to query or search on a xml content.  Using a bunch of tables also gives you the flexibility of presenting content items that you have not designed before, unlike xml which is more rigid.

Regarding the creation of a new CMS package.  Some have seen the alpha state of it.  Although its been 2 months now since anything moved as its not the one that is putting food on the table.  Although I agree with Jeff on some degree that fixing the current UI of the CMS maybe easier.  But on my case Robert Locke's advice to me still holds "adding is easier than subtracting".  Also the fact that in most cases CMS may function alike but almost each clients wants a real different UI.  The UI that works for their business/style.  So if I am able to put the changing stuff in the which is mostly UI on another package.  And the less changing stuff on another package.  The theory is that when another client wants a different UI, atleast I know which parts that will not change.  There is a clear distinction between UI part, service part and serving content part.

Hope this is inline with the discussion.