NB. You need to make an index first.
If you have not already made an index of the Cocoon Documentation, you may do so here.
This sample currently does not work. This sample used to use the docs built-in to Cocoon as a search target. While the new documentation effort is in flux, there is nothing to index. Try this sample in the current 2.1 version.
You can perform any of the following search types:
You can view, reuse, and re-edit your previous queries:
Allows you to assemble complex Lucene Queries without having to use the Lucene Query Language. Keeps a list of the queries you have performed in it's history (for as long as your Session lasts). Allows you to re-use and edit them.
Through a combination of FlowScript (controller), CForms and JXTemplate (view), Beans and OJB (model), i18n and the CocoonLuceneSearcher component.
Cocoon Forms provideds the infrastructure to manipulate the Beans via HTML Forms. That is to change the Properties of the Beans and add and remove Criteria.
JXTemplate is used to show the results and the history (List of Query Beans).
The results are in the form of a
Maps. Each Map represents a search hit. It contains the
rank of the document, plus any Index Fields you arranged to have stored in your Index by Lucene (in this sample, the only stored field is the
The history is in the form of a
List of Query Beans.
The Beans represent an abstract (and persistable) representation of your Query.
i18n is used to hold all of the display strings used by the Application. Form labels and hints, Query descriptions, Screen labels and hints, Error messages etc.
This is the Component that does the actual searching. It is provided with the Lucene Directory and a Query by the Query Bean. If you give it a directory parameter that is a single folder name, it uses that folder in the Servlet Engine's Work Directory, if the parameter is an absolute file path, it uses that instead. It uses the default Analyser.
If you are happy with the existing forms, then all that really needs to happen to be able to re-use this sample in your own projects it to set up the menu of Search Fields, so they match your Search Index.
When the Lucene Index of Cocoon Documentation that this sample uses is created, tags within the documents are turned into Lucene Index Fields, which can be searched individually. The names of these fields are for example:
Cocoon Forms is setup to load these menus (selection-lists) from their own files. The
simple search form uses the file forms/simple-fields.xml, while the
advanced search form uses the file forms/advanced-fields.xml.
Edit these files to match your own Search Index, for example, the item:
<fd:item value="title"> <fd:label><i18n:text i18n:catalogue="local">field.title.label</i18n:text></fd:label> </fd:item>makes a menu item using the i18n key
field.title.labelas the menu text and
titleas the value, where the value matches one of your Index Fields.
Once your CForms selection-lists are setup, you will want to edit the existing i18n message keys in i18n/messages_en.xml and/or provide new message files in your own language.
The last thing you may choose to do, is to supply some CSS for the screens. The history, favourites and results screens supply what is hopefully a rich enough collection of CSS Classes, have a look at the HTML output to see what there is.
If you know CForms, it would be relatively easy to develop your own Forms (Model, Binding and Template). If you follow the existing naming scheme and you choose a new name for your form, it may not even be necessary to edit the Sitemap.
Depending on how different your Forms are to the supplied ones, it may or may not be necessary to edit the FlowScript. It is quite possible that this will not be required.
It is possible to build Lucene Queries that are more complex, or specialised than those produced by these sample Beans. To do so you would have to at least implement your own CriterionBean. You would probably need to rewrite the FlowScript to handle your new Bean.It would also be possible to implement different kinds of Queries, like those that used the Hibernate Criterion API.
There are two Interfaces and two Bean Implementations of those Interfaces in the sample.
o.a.c.bean.query.SimpleLuceneQueryBean represent a Query, which has a Collection of
bool property of the QueryBean specifies how the multiple criteria are combined. The
field property of the CriterionBean specifies which Index Field to search, the
match property specifies how to match that field and the
value property, is the string from which Terms are extracted. All the rest is candy.
Both the Query and Criterion Beans were designed to be Persistable using one of the Object-Relational mapping tools like Hibernate, OJB etc. This sample currently uses the HSQLDB instance built in to Cocoon.
Copyright © 1999-2010 The Apache Software Foundation. All rights reserved.