Forum OpenACS Q&A: General comments data model

Collapse
1: General comments data model
Posted by Dave Bauer on 04/17/03 09:23 PM
I have a need to extend general comments to add the trackback ping capability. In looking at the general comments data model, geneal_comments extends acs_messages, but is not an object_type.

I was going to further extend the general_comments object type, but as it does not exist I am not sure what to do. Should general_comments be a subtype of acs_message?

Collapse
2: Re: General comments data model (response to 1)
Posted by Don Baccus on 04/17/03 09:35 PM
A handful of packages were written this way, and no, it should not be subtyped from acs_message.  In fact if you can figure out a way to write an upgrade script to get rid of this in existing installs we could rewrite the datamodel to be more sensible.  It probably wouldn't be that hard to do, in general munging the type of an object isn't that big a deal.
Collapse
3: Re: General comments data model (response to 2)
Posted by tammy m on 04/18/03 10:08 PM
Hi

I was looking at general-comments data model too, to add some Search support to general-comments. Could you point me to a package that was written "the right way" with respect to the data/object model? Should general-comments subclass acs-message-revision in the manner static-pages subclasses content-revision? I know object-munging might seem trivial to experienced OpenACS-ers but us newer folks find it a bit less trivial. For instance, it is not apparent to me how changes to object types might affect the workings of other packages as object type changes are not literally inherited as a true OO system... it seems optional to have "correctly" implemented object type checks in other packages and that things could easily break if object changes are made... any tips on how to best navigate these waters?! And by the way, what is "trackback ping capability?!"

Collapse
4: Re: General comments data model (response to 1)
Posted by Dave Bauer on 04/19/03 01:44 AM
Tammy,

Because general-comments are not an object type, you can't create a search service contract for just general comments. You would have to associate the service contract with acs_message.

A refined general comments data model would directly subtype content_revision and store comments in the content repository. I am not sure how to handle attachments. I like the idea of handling upload of attachments in a standard way, but I don't feel the attachments package is the right way to do it.

I will post a new plan for a general comments data model and api in the next week for review.

Collapse
5: Re: General comments data model (response to 1)
Posted by Dave Bauer on 04/19/03 01:52 AM
I forgot to explain trackback.

Here is the spec: http://www.movabletype.org/docs/mttrackback.html

And an example of trackback between weblogs: http://www.intertwingly.net/blog/1336.html

It is a method to notify a web site when you link to it. The linked to site can then present this information in its own way. My idea was to present trackback information as comments.

I made created a test implementation for lars-blogger, but I think there is a much greater potential to make is a standalone package to trackback enable any object.

See also:
The OSCOM conference has trackback enabled the pages describing the talks planned for the conference: http://lists.oscom.org/pipermail/participants/2003-April/000135.html

O'Reilly has trackback enabled the pages for their Emerging Technology Conference also http://conferences.oreillynet.com/pub/w/22/tutorials.html

Collapse
6: Re: General comments data model (response to 4)
Posted by tammy m on 04/21/03 05:52 PM
Hi Dave,

I was looking for a object_type to subclass with general-comments so that I could implement Search. I didn't think it would be the right way to implement the search on acs-message-revision because that object_type is not associated with a static-page and the Search contract needs to get a URL -- I wanted the URL to be to the static-page the general-comment is associated with.

It makes sense to make general-comments a subtype of content_revision directly if we really don't need to use a functionality that acs-message-revision + acs-message were providing.  I'm new to OACS so I am not really sure how much acs-message functionality general-comments relies on. If it's just storage I guess that would not be hard too to replicate.

I'll be looking forward to your data model + api:)