actually I've gained total control over the verity engine by using a query
to populate anohter query which I create. I make one "custom" field which
is usually a comma delimited list. In this list I store the name of the
component I'm searching (more usuaful when I'm searching more than one
component) the url of an individual listing (to which I pass also the id of
the specific item) and in the case of a forum resule I also store the thread
ID and the message ID in this list. Then in the search action page I just
loop through the list to gain access to all of these other variables.
Its worked really well so far.
-----Original Message-----
From: Johnson, Russ [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 08, 2000 3:17 PM
To: Fusebox
Subject: RE: building a fusebox friendly verity(other?) search engine
I had asked Hal Helms and Nat Papovich about that very thing at the Dev
conference in November. Hal hadn't really messed with it too much and Nat
said the only solution they came up with was extremely sticky so they stayed
away from it as much as possible.
Hal suggested I do a little research on it and see if there was a viable
solution. So, I have been beating my head against a wall since the Dev
conference trying to come up with a "simple", usable solution.
I broke this into 2 parts, the first being the problem with the return URL
that verity gives you will only point directly to the file that it returns
in your results. This takes you out of your Fusebox by not calling the
index.cfm page in that circuit.
The second was coming up with a solution that would allow the verity engine
to only index the dsp_ files since that is where I keep most of my static
content. I didnt want to index the act_, app_, or qry_ files since they are
really supporting files.
I have *almost* solved the first issue with a simple custom tag call at the
top of each dsp_ file that you index. It takes 2 arguments, the fuseAction
that you use to call that fuse in the index.cfm file and a dynamic page
title for the fuse if you use them. It seems a little cumbersome at first
but I havent been abot to come up with any thing that is easier.
The second problem has been quite a bit harder to find a solution for. I
havent really found a way to filter the circuits in an application and only
index the dsp_ files. The closest I have been able to come to solving this
is by creating a circuit called "content" and placing all of my static dsp_
files that I want indexed in it. Create a collection on that circuit and
use the custom tag and it has been working pretty good so far.
You can search multiple collections by creating a comma-delimited list in
the collection field so this gives you the ability to search your fuses and
the database content.
I hope to have a better solution for the indexing part pretty soon. I have
recruited some help to come up with an app that will handle it for you.
I'll let you know as soon as I finalize the custom tag for the dsp_ files.
I really only have to add my exception handling to it and it should be
completed.
Hal sure knows how to drive someone out of his mind!! BTW Hal, you'll be the
first to know when it's complete. I remember you saying you wanted to take
.....erm, credit for it!! :o)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
