AjaxSearch 1.5 now with Mootools

I have been working on some upgrades to AjaxSearch and would love to get some feedback before adding this one to the repository and future releases. Feedback/Comments would be appreciated. I have not updated all of the documentation but all of the functionality should be there.

Here is whats new:

• Updated search code to use all of the fixes/updates from the AjaxSearch forum thread.
• No longer uses Prototype/Scriptaculous, the js has been rewritten to use MooTools.
• Added support for language files so snippet code no longer needs edited to change text items.
• Added template support for customizing output. Look in the file templates.inc.php. Due to the ajax I am not using chunks, you have to change this file to change the template.
• Maybe some other things I can’t remember

I would like to see some of the features from HyperFlexSeachForm being included in AjaxSearch, such as limiting the search to certain template or parent folder. In addition to that, I think that it the snippet should search for $keywords and htmlentities($keywords) by default as the RTE’s does htmlentities conversion..

How about the ability to search specified TVs as well as the standard fields?

Quote from: ZAP at Jan 22, 2007, 04:14 PM

How about the ability to search specified TVs as well as the standard fields?

TV’s are typically dynamically processed, so it’s generally not much use to search the content of @INHERIT or @EVAL, or unprocessed lists of data. And the same problem exists in the standard fields. What if I use tags to dynamically create a pagetitle or a snippet to get descriptions? What really needs to happen is an external search index needs to be maintained with content as it is output through valid paths, and this is the direction MODx searches will be taking in the near future.

In the meantime, a few joins and additional OR clauses might work to get the raw content anyway...

I’ve used external search engines/indexers in the past, and generally they were a pain to reindex all the time (usually I set a crontab, but that just seemed clunky to me). So if MODx is going to maintain an index of page output in the future, then I would suggest that there be a simple trigger that can be called whenever page output is updated (by Jot, for example) and that it be capable of reindexing only the new content. This also raises the question of whether this data would have any relation to the cache files or not (since this would include much of the same info, but with tags and code stripped out).

Personally I use TVs for non-dynamic content regularly. For example, sidebar content or other info specific to that particular document. I would think that a standard routine (a la Ditto) to include those TVs when searching would be useful for many people. And I actually add randomized content to my pages a lot, and I wouldn’t want that content indexed for searching. So the future system that parses actual document output would need to also include something like the ability to set flags in comments for what not to search.

In the meantime, sure I can hack the queries and add join statements to them, but not everyone is going to feel comfortable messing that deeply with the code.

Hi Kyle... got the updated AjaxSearch.php file (adding "as." to the "resultClass" on line 121, but I’m still not getting any results in either Fx or Safari.

I would love for Ajax search to be able to produce a results page as a rss feed

Quote from: ZAP at Jan 22, 2007, 07:16 PM

I’ve used external search engines/indexers in the past, and generally they were a pain to reindex all the time (usually I set a crontab, but that just seemed clunky to me). So if MODx is going to maintain an index of page output in the future, then I would suggest that there be a simple trigger that can be called whenever page output is updated (by Jot, for example) and that it be capable of reindexing only the new content. This also raises the question of whether this data would have any relation to the cache files or not (since this would include much of the same info, but with tags and code stripped out).

This would be a custom search index tightly integrated with the core, which could be configurable to allow users to maintain search indexes of any kind of data, from any source, into custom indexes for specific purposes. Check out Lucene or Zend_Search_Lucene for examples of this kind of flexible search infrastructure.

Quote from: ZAP at Jan 22, 2007, 07:16 PM

Personally I use TVs for non-dynamic content regularly. For example, sidebar content or other info specific to that particular document. I would think that a standard routine (a la Ditto) to include those TVs when searching would be useful for many people. And I actually add randomized content to my pages a lot, and I wouldn’t want that content indexed for searching. So the future system that parses actual document output would need to also include something like the ability to set flags in comments for what not to search.

What you include in the indexes would be completely configurable. You could maintain indexes for private access, one for public access, and another with indexed PDF content linking to the PDF files it was indexed from. There would be a standard API for searching the index, creating and building indexes, and keeping them up to date.

Quote from: ZAP at Jan 22, 2007, 07:16 PM

In the meantime, sure I can hack the queries and add join statements to them, but not everyone is going to feel comfortable messing that deeply with the code.

Didn’t imply they were, just spelling out the technical challenges that must be overcome to provide a robust and generic solution to this problem of indexing/searching content that can be dynamic and/or static based on all kinds of variables, and would otherwise never have a chance to be searchable.

Sounds very nice indeed. I especially like the ability to index PDF files (and other document types, I assume). Hopefully updates to the index would be automatic and hassle-free once it were set up, because I really hate it when I have to get up early to milk the server every morning.

Quote from: ZAP at Jan 23, 2007, 11:30 AM

Sounds very nice indeed. I especially like the ability to index PDF files (and other document types, I assume). Hopefully updates to the index would be automatic and hassle-free once it were set up, because I really hate it when I have to get up early to milk the server every morning.

Absolutely, the index would be maintained by API -- so when objects were saved you would update the index, or for things like PDFs, when they are uploaded into a directory via a manager interface. Of course, it would also allow cron-jobs to update certain indexes as well as be configured to update after certain lengths of time, etc. Since it’s programmatically controllable, the possibilities for maintaining those kinds of indexes is limitless. There are some challenges to be worked out though, especially in regards to character encodings and other such details...