unfortunately, that didn't solve our problem.
I did come up with a solution, and I thought I would post it for the edification of all.
SOLUTION:
I just ripped out the spectra search and built my own from scratch. (Sometimes a really sharp scalpel is the best tool)
Here's how I did it...
I decided that all we really want people to search is entire pages of content (not each individual content object since that often brings back duplicates that I had to screen out anyway).
In our case, we have a few object types that are "page" types. The "page" objects contain other objects that make up the body of any given page but do not include extra stuff like navigation.
So, I did a query to bring back the objectIDs of all the "page" type objects excluding those that are not yet published, not active, aborted, saved in-progress, etc.
Then, I looped over the results of the query and called the "display" handler for each "page" (NOTE: This is NOT scalable... but we have only 400 active "pages" that must be indexed, so it will work for us... plus this job only runs at night in the backround and could be split into multiple small jobs to make it more scalable... BUT, if you want to use this solution yourself, make sure you're aware of the impact)
I used the <cfsavecontent> tag to save the results of each display handler as a var and then used <cffile> to write a static copy to a dir called "SearchResults". Each static file is a .cfm file with well formed HTML header/footer added, a <title> tag, and a <cflocation> prepended to the top with the actual live url of the page. Each file is named according to the following convention [ObjectID].cfm
I then used a simple <cfindex> to index everything in the SearchResults dir and populate a single collection.
>From there on out it's just simple verity searching on a single collection. Since I took the time to write the well-formed HTML shell around it and added the <title> verity figured everyting out and formatted it beautifully. The url returned for each record returned from the search is the url of the SearchResults/[ObjectID].cfm. The user clicks the link and is taken to that file which (as you recall) is prepended with a <cflocation> to the actual url of the live page.
Ta Dah! Your own custom search that COMPLETELY bypasses Spectra. (hah! in your face Spectra!)
Of course, if you want to use a solution like this, you should consider your situation carefully.
- You will need to account for the inherent lack of scalability (in our case, it works because we have only a few hundred pages to generate and this number has stayed constant over the past 2yrs. Old pages drop off over time and new ones are added).
- Also, this plan bypasses some of the advanced features of spectra's searching (metadata, Keywords, etc) in our case we found that stuff to be overkill... Spectra has proved to be WAY too difficult for our content contributor folks to handle so we've simplified as much as possible and elimated things like keywords & user-defined metadata.
-Finally, you need to consider how tightly woven into your site your current search tools are. Ours consist of basically one processing page that calls a single custom tag. We also have multiple search forms that post to that single point, but that's not a problem. If your search is much more extensive and less encapsulated, you may have problems implementing this solution.
All that said, this worked for us. And if you're like us... forbidden by management from euthanizing Spectra... the satisfying feeling of amputating one of its grotesque limbs is still pretty nice.
Thanks again to Derek for the assist.
-Michael Conger
[EMAIL PROTECTED]
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
