An alternative AJAX-based autocomplete approach is described in Rendering paragraphs with AJAX. Here are the pros and cons of each approach.
- The keyword file must be regenerated manually when a new term is added to the index. This means that the autocompleted terms are not always in sync with the index.
- Slower. Queries the server every time the user requests new autocompletion. The result set can be very large and take a lot of memory.
- You can speed up the search for example by executing the query only after the user has typed the first three letters. Smaller result set.
- Works well when content changes often. The completed keywords are always in sync with the content index.
- Works well when you limit the search to a subset of content. For example, search only contacts or only FAQ pages. Smaller result set is faster to work with.
- You need to write a new class for each new subset of content.
Add name and id attributes in the input field
id attributes in the input field. Set their value to
query. Add a div element with id
autosuggest somewhere on the page. This div will be dynamically attached to your search field.
Here is an code snippet from my homepage:
Add a tag
You need a tag that is called in one of your templates that actually reads the search terms from the index and writes them to the .js file. Since the JCP can be run with different implementations, the tag uses internally an specific implementation for your corresponding index. In my case it is the Jackrabbit implementation (this is the one that comes with Magnolia samples). Therefore you need to add three files to your classpath.
- GetSearchTermsTag.class This is the tag.
- GetSearchTerms.class This is an interface.
- GetSearchTermsJackrabbitImpl.class This is the implementation class to use with Jackrabbit.
The tag returns the path to the written .js file. For example
You would use something like this.
Import CSS styles
Import some styles to make everything look like a drop-down menu. This is a snipped of the CSS used for my autosuggest.