Home
The Toolkit for Online Communities
17206 Community Members, 1 member online, 1721 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Idea: New Content Paradigm : One Message

Forum OpenACS Development: Re: Idea: New Content Paradigm

Collapse
Posted by Tom Jackson on

Jeff, all good points. As I said I am looking into using the CR, and I was thinking of breaking down my cr_items as much as possible. I like the idea of being able to relate any item to any other item, plus the idea of parent/child relationships is useful. I've had not much interest in the automatic insert/update/delete stuff since I use my own code for that, but I should look at what it is doing more closely.

I know it has to be good stuff, but my pea sized brain always seems to have trouble grasping other people's code.

Collapse
Posted by Jeff Davis on
Jim, the big advantage of the CMS insertable view trick is that you don't hit any limits on number of parameters as you would with __new things in postgres. It supports defaults in the metadata (and in the table definition). The only disadvantage would be if you really do need to do anything fancy in the new method (although for CR items that seems mostly not to be the case). Of course if you are talking about small bitesized things with few attributes then that is not an issue. For photos for example if you create attributes for the useful exif data fields you already have more that 16 fields. Given how many things are gobbled up for just the basic metadata this seems to be a serious problem for most types.

Talli, there is a table cr_revisions_attributes which is supposed to hold an XML representation for a given content revision and there are things in oracle to generate the XML (although I have not looked to see if this is present in postgres). The intent is to use it as a secondary representation of the given revision (intended originally for indexing I think but there is no reason you couldn't use it to feed an XSL styling step or embed in a larger xml document to export a content collection). It's not really related to RSS at all (other than both things are XML). There is not any provision for making the primary datastore XML rather than table based, although you can of course store XML in the content field, there just is no pleasant way to query it other than with full text search really or other RDBMS things to it (like sorting or updating).