Forum OpenACS Q&A: Site Wide Search in acs-messaging or general-comments?

1: Site Wide Search in acs-messaging or general-comments?

Posted by tammy m on 04/03/03 01:48 AM

According to the acs-messaging docs, the package provides a general framework for site wide search for packages that use it as a substrate. general-comments uses acs-messaging. However, I can't seem to find support for site wide search in either of these packages. Am I missing something here?

Are general-comments at this time only being indexed for search when the static-pages package has it's file system scan run?

I see that the general-comments I add get into the search queue but there is no FTSContentProvider service contract defined for acs-messaging or general-comments:

[02/Apr/2003:12:49:34][1926.2051][-sched-] Notice: Querying 'select acs_sc_binding__exists_p('FtsContentProvider','acs_message_revision');'

Any info on how to best go about implementing site wide search for my general-comments would be appreciated;)

I'm guessing I would implement FTSContentProvider for general-comments and have the URL and datasource point to the corresponding StaticPage. But then I fear that duplicate entries would exist in my search results page. How do other sites get their GeneralComments on StaticPages updated and into search results on a more or less realtime basis?

Anyone?!

2: Re: Site Wide Search in acs-messaging or general-comments? (response to 1)

Posted by Joel Aufrecht on 04/03/03 03:16 AM

By copying from another package I got a working example in my earlier tutorial, but I don't have a full understanding of how it works so I'd be very happy if people could correct me.

First, we create a function that will return the url of an item (this seems like something that ought to be a global standard, like __name. I ran into the same need trying to upgrade the "About a user" page that shows all of a user's objects.). We also create a __datasource function but I don't yet understand why.

Now we create one or three service contracts (one contract and two aliases? What's an alias? Why?) Then we set up database triggers to update the full text search index whenever content changes.

I think that's it. Good luck, and if you figure it out better let me know so I can put it all in the advanced tutorial.

3: Re: Site Wide Search in acs-messaging or general-comments? (response to 1)

Posted by Dave Bauer on 04/03/03 03:37 AM

You shouldn't need to create triggers because the comments are stored in the content_repository.

The datasource service contract implementation returns the actualy content to be indexed to the indexer. So for general comments, it would be the comment text.

The implementation_alias is the tcl proc that actually implements the operation for the service contract.

Using the search package with OpenFTS, there isn't a solution yet to only show the link to a parent item. That can easily be seen by searching here at openacs.org. Each reply to a message is indexed, and a long thread can show many listings to the same thread for a search.

4: Re: Site Wide Search in acs-messaging or general-comments? (response to 1)

Posted by tammy m on 04/03/03 11:38 PM

Thanks Dave and Joel:)

Right I don't need to implement triggers for general-comments because I do see the general-comments object I add go into the search_observer_queue. Actually it turns out to be a acs_message_revision object.

Because the object_type of the acs_object that general-comments inserts in cr_revisions is acs_message_revision (not general-comments specific type), I guess I should implement the FTSContentProvider service contract on acs-messaging (not general-comments)? Since acs_message_revision is the object_type that the search_indexer proc will be looking for when it needs the procs that FTSContentProvider provides.

But this brings up another issue because I suppose I can use the content/datasource from the acs_message_revision object BUT I want to have the URL for the StaticPage associated with the GeneralComment returned. I can think of a few really hacky/kludgy ways to do this (have the acs_message_revision url sc proc run some query to see if there is a StaticPage/GeneralComment related to the acs_message_revision) -- but none of them are very object-oriented. I mean an acs_message_revision should really NOT be expected to know about all possible object types that might refer to it in the future and account for them.

So that brings me to the bigger question of what is the "right" way to use the acs_objects and acs_object_types to do this? I'm afraid to create a general-comments object type for fear it might break something in the acs-messaging or content-repository (some code that looks at object types to provide some service that already works with these types).