Forum OpenACS Development: Ideas for Content Management
I've written a proposal for a content management package I'm planning to build with OpenACS4. It's posted at http://www.musea tech.net/etp/editthispage.html.
The requirements it presents are sufficient to build many of the websites we've been getting RFPs for lately. These are information- providing organizations that have reached the limit of what they can do with static pages, and are looking for a system that helps them get organized and work more efficiently. Since I see this package as something that's potentially useful to the whole community, I'd appreciate it if you could use this thread to tell me what you think.
With regard to comments, they could either be retrieved from the database or written to the published file.
With this type of system the pages could actually be rendered into HTML if there were no parts that needed to be queried from the database on each page read.
I don't have time to go back and look at the paper at the moment, but when I did read it I had the impression that the edited pages were stored in the filesystem, with auditing provided by CVS.
requiremenst 20.10.1 and 2 could be eliminated having 20.10.5. I've read that Netscape 6 will make the DHTML for "wysiwyg editing in a form" much easier (compatible with IE).
we discused some of this in this thread.
there are some tools like webeditpro that makes this possible. How about adding a requirement that makes pluging these tools easier? I am thinking in something where we can add weeditpro (or whatever we write later) to all the forms by just turning on some parameter.
The final requirement (for performance) says that there needs to be some caching, so that if you request the same page multiple times, we're not sending many identical queries to the database to get the content for that page. That probably involves writing a scheduled proc that goes through the cache and culls anything that has expired - we don't want all the content requested in the lifetime of the server process hanging around in memory.
With cached content from the db for each page, performance benchmarks should be competitive with any other templated page. And since the templating system compiles ADPs into bytecode, they perform pretty well.
I don't have time to go back and look at the paper at the moment, but when I did read it I had the impression that the edited pages were stored in the filesystem, with auditing provided by CVS."
ETP will be fully stored in the DB. For UPO, our CMS hack used CVS and the file manager because that was the easiest and fastest way to build it, considering we were using 3.2.4.
You should probably be using the content repository, no?
Michael Slater's post today over <a href="http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001jz&topic_id=13&topic=OpenACS%20CMS">here</a> mentions a technique for creating a categorization taxonomy for content items, and that alone is enough to make me want to use those tables.
I also need to store images in the database - what is the general opinion on using the cr_revisions table for this as opposed to rolling your own? Again, the possibilities for categorization are compelling to me. Has anyone had experience with creating a huge image catalog using the CR datamodel?
Originally I was trying to keep the ETP package as simple as possible, so naturally I avoided relying on the 28 files and 10000 lines of code in the acs-content-repository/sql directory. Of course I also recognize the benefits to be had from code reuse, and perhaps using the CR doesn't necessarily mean more complexity. If anyone can list the other benefits it brings here, that would be useful.
It also allows storage in the file system rather than in the db, and packages might want to (optionally) expose that choice to system administrators when the package is mounted, etc.
And we'll be building our sitewide search facility on top of the CR (in PG's case), so clients will get that for free.
<li>Complexity. As you've mentioned, the CR comes complete with folders and the like. Not sure I would've made that decision myself.<p>
<li>Unknown Scalability. In theory, indexing helps a lot here, i.e. every time you double the number of items the cost of accessing an item goes up by a factor of log2. For large binary content the cost of delivering it is high regardless of any overhead in accessing it. The LRU cache employed by any reasonable RDBMS should keep localized references in RAM, and if the usage pattern is such that you start getting disk I/O this would be true even if various packages were rolling their own.
<p>So, I don't see any particular reason why the CR won't scale reasonably.
So at this point the CR seems to be a win rather than a lose. As time goes on we may learn otherwise, but that's the current thinking.