Home
The Toolkit for Online Communities
17612 Community Members, 0 members online, 2764 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 Jun Yamog on
Hi Jeff,

I am assuming I am Jim, since Jun is the closest to Jim :)

Yes indeed I agree that inserting to a view is a lot better than calling __new.  This is why I use this method in the CMS I am trying to make.  I submitted also a small fix to DanW about this.  Another plus is it makes query to be db independent.  Well atleast if the db supports rules in views, plus DanW good hack.  I also use the view now just for inserting, I also use cr_foo_typex to get some stuff.  Sometimes its more convinient than joining acs_objects, cr_items, cr_revisions and foo_table.  Not sure if its fast or not.

So if anyone is planning to inherit from cr_items and will need revisioning (some weird decision) this is one thing that I am sure will not work anymore.  I did not follow this path, I am too lazy to create my own.  Also my non primary objective is to be CMS compatible.  That means BCMS will be able to manipulate the CR even if CMS is handling it, and vice versa.  Again its not a primary objective, but a nice to have.

Talli,

Jeff says it better than me regarding storing XML.  Although it possible to mix them both.  This is what I am employing right now, although its not OACS.  I believe its applicable to OACS too.  I have a table with columns that are important for the content type.  But the main body/content still have a lot of XML.  This XML is not important to relate or be a living entitity.  (Well at least not yet, it will be some real work putting this into table columns).  XML attributes like footnotes, chapters, etc.  They haven't been warranted to be living in a separate column.  But the end result is still XML, constructed from the table columns and body/content that is XML too.

Collapse
Posted by Jeff Davis on
Actually Jim = Tom (I was writing a note to Jim Lynch at the same time which was why I got it wrong).

On the view approach I was talking about the relative merits of something like Tom's query writer (or package_instantiate_object which is more or less the same thing) and a view based approach. I think qw is useful but given how quickly it breaks down on postgres I think it can't really be the basis of a generic content attribute editing system.