First I modified the form so that new fields were available for the above-mentioned limiters. The fields are in a shContent div so that they aren't always shown. When the user clicks an "advanced options" link the new fields are shown. Second, I added some conditionals to the query builder so that the new fields are processed.
For the modification date fields I included a JavaScript date picker that I scarfed from http://www.howtocreate.co.uk/jslibs. I had to make a few changes to the script to get it to work more like I wanted. I think it looks pretty good, though it could definitely use some updating. Of course, some of the updates I have in mind could break it for Nav4. Not a problem in this particular instance, but perhaps a bit of a hassle for further usage.
There's a good amount of information stored in the IS catalog (beyond the content index) that can be searched using catalog field references. With this in mind I could have provided even more options for search parameters, but I didn't feel like taking the time to investigate what was available to search and what syntax would have to be used. The changes I've made are really just for FM anyway because nobody else (as far as I know) really uses the file search.
Index server provides a couple of different ways by which to search the information in the catalog. I used a single search method to make it easier to code and use. The file name and modification date are searched via catalog field reference (e.g.
@filename index.htm
and @write > 2005/06/01
). The path is limited using the query utility's scope function rather than searching on the path field.The field search provides a lot of flexibility when used with wildcards. I've been having some trouble figuring out the various syntax options, but I think I'm starting to get a bit of a handle on things. Still, some of the syntax options throw me off a bit so I would need to do a bit more reading before I felt comfortable using them.
I think the search syntax would be good information to provide were I to develop some kind of help documentation. With that information the user could perform more advanced searches without me having to cook up more options. That's very low priority, though, and I don't expect to ever get something like that done. For the time being I've tried to use what I think are the most generic search parameters so that the user does not have to really know much about the search syntax in order to get useful results. No doubt I'll hear feedback if things don't really work out that way.