Forum OpenACS Development: Categories in OpenACS 4

Posted by Dave Bauer on
It looks like the Content Repository has functions to duplicate the
category features of OpenACS 3.x. It also appears that the only
package to use this is CMS. BBoard, and a couple others I forget have
their own tables for categories.

Is it best to use the CR categories or to build your own into a
package? I am wonderng about efficiency of the lookup for categories.

Posted by Don Baccus on
We should use a single centralized categorization service, i.e. that provided by the CR.  At least that's what I think.  This makes it possible to categorize all sorts of content on the system and expose it to generalized code that sifts and sorts content based on various criteria.  I.E. the basic nuts-and-bolts of knowledge management.
Posted by Malte Sussdorff on
I would second Don's notion. For the user interface I'd suggest that you have a link which allows you to create a tree view of you categories so you can pick one. Look at and something like this popping up when you want to add an item to a category. For code and demo how this works with ACES check it out from CVS (at
Posted by Jun Yamog on

Would you think it would be wise to store this categories in memory?
Right now I am getting for my pages to use CR.  So I have a navigation
bar for my pages which can be a category basically.  I have done it
initially using lists of keys to look up arrays.  I think getting this
stuff from memory might be faster than getting it straigth to the
database.  Context_bar gets everything from the database each page load.

Is it better to cache things (small things) in memory than get it from
the database?  If yes what is the best way to do this?

- Make your own init proc that gets the db contents and puts in your
data structure.

- Use memoize stuff

- Use ns_cache

- others.

What is the best way to cache contents from the db like the categories
from CR?


Posted by Don Baccus on
I'd use the memoize stuff - in OpenACS 4 it uses ns_cache so I don't think there'd be much advantage in using it directly.

As to what to cache and what not to cache, there's obviously a tradeoff in the use of memory (caching is PER THREAD I believe, not PER AOLSERVER INSTANCE) for caching vs. more RAM for the database and filesystem cache.  Complex queries are certainly worth caching, if they're hit frequently, but are simple queries?

One weakness of the current design is that there's no way to parameterize what should and shouldn't be cached.  Then again, with hardware so cheap it's no big deal to stick a separate webserver box in front of the DB with a GB of RAM and have it cache like hell ...