Forum OpenACS Development: Search on general-comments interacts with Object Model, CR, acs-messaging?

Collapse
1: Search on general-comments interacts with Object Model, CR, acs-messaging?
Posted by tammy m on 04/10/03 01:02 AM
Hi

I have been looking into implementing Search capabilities on the general-comments package. This is not exactly straight forward to me. For one thing, there is not a general-comments object_type. What gets inserted into the search_observer_queue for a "general-comment" is actually an object_id of the acs_message_revision object_type. This poses all sorts of interesting dilemmas in how to best go about implementing Search capabilities on general-comments. At least for me! Maybe someone with more OACS experience can lend some insight?

The way I see it, there are at least 3 possible ways to implement Search on general-comments. Only one of them appears that it might be trivial, but that also seems to be the wrong way to go based on what I've read of the intended use of the new OACS Object Model:(

Anyone care to comment on my thoughts so far?! Am I understanding the way Search +/or the Object Model work in OACS or am I just making myself nuts and it's way more straightforward than it looks?!

METHOD 1
Create a new object_type for general-comments that implements FTSContentProvider sc-procs.
Unknown
If I create a new object_type for general-comments, does it break acs_message/revisions storage in CR? Do any procs in acs-messaging or content-repository packages look at object_type in order to implement any behavior they rely on for CR functionality to work?
As a note here, the search_indexer only looks at the current object_type (supertype/parent object_types are ignored) for sc-procs (FTSContentProvider) to get an object into Search.
I cannot readily see how to query the object hierarchy for a given object instance (object_id) or an object_type. Maybe this is related to the tree_sortkey thing somehow?
Known
general-comments is associated with static-page which has the URL we are looking to return in our Search results. Can get the URL via general-comment's object_id (actually the associated static_page object_id) in general_comments table (general-comment's object_id is called comment_id in this table). Can get datasource (content) we want via acs-message-revision's associated cr_revision title + content fields. Be sure to put latest revision only into search. Be sure revision is live/visible. If use associated static-page for URL, assumes any object_type that will have general-comments associated with the object_type (e.g. static-pages in this case), will provide a URL in the same way (tcl/sql proc, etc). Use object_type__url proc?

METHOD 2
Implement FTSContentProvider sc-procs on cr_revisions. Change search_indexer to also check supertype/parent types of objects in queue for sc-procs

Known
Does underlying cr_revision or cr_item have a URL associated? Not the one one we would want; to the static-page associated with the general-comment.
Does cr_revision or cr_item implement sc procs (for FTSContentProvider)? Yes, acs-content-repository does (content_search__url). The URL returned from its proc though would be to something like $OACS_ROOT/acs-content-repository?revision_id=$object_id (where object_id is the revision_id of the latest acs-message-revision in this case).
Would not give us what we want returned in our Search results page. We want the results to have the URL of the static-page the general-comments are associated with.

METHOD 3, Simplest/ugliest way!
Implement FTSContentProvider sc-procs on acs_message_revision.

Known
Wouldn't work to implement FTSContentProvider sc-procs on acs_message/revision as the URL we want our Searches to return (that of the static-page) is not associated with this type of object. The acs-message object does not relate back to the associated general-comment (except through the general-comments table, which would not apply to all acs-messages).
This way does not support the pseudo-object-oriented Object Model of OACS very well. We'd be using a supertype (acs_message) to create FTSContentProvider sc-procs that would be checking if a specific sort of subtype (general_comments; though not even really a subtype in this case, just a rather loosely associated object_type) existed for the current acs_message object. If there was a general-comments table with acs_message_id as its comment_id, then we'd have access to the static-pages URL for return to Search.

This seems like a real hack. But would probably be much easier for this newbie to implement! Unless we break the Object Model and do something messy:
For URL, check if a corresponding static-page for acs-message exists in general-comments table. If so, return it's URL. If not, return URL the way that CR does, e.g. something like:

    set package_id [apm_package_id_from_key acs-content-repository]
    db_1row get_url_stub "
        select site_node__url(node_id) as root_url,
               (select content_item__get_path(item_id,null)
                  from cr_revisions
                 where revision_id = :object_id) as url
          from site_nodes n
         where n.object_id = :package_id
    "
    return "[string trimright $root_url /]$url?revision_id=$object_id"