XMod Pro makes it a pretty painless process to add, edit, delete, and view your data in a DotNetNuke website. However, until XMod Pro 4, you couldn't integrate that data with the built in site-wide search DNN offers. Now you can.

Integrating with DotNetNuke's search mechanism is fairly painless for those modules that have limited or restricted data schemas. XMod Pro, though, is designed around flexibility and empowering you to determine what gets displayed and how that data is displayed.

When it comes to DNN search integration, though, that flexibility becomes hard to squeeze into the rigid framework required by DotNetNuke. With version 4, we think we've cracked it though. You get the integration that comes with DNN search while maintaining much of the flexibility you've come to love from XMod Pro. Here's how we did it...

First, DotNetNuke's search is implemented on a module-instance basis. So, you will configure your search integration on the Configure page for each XMod Pro module instance that you want to participate. Here's what that page looks like:

Don't be overwhelmed by the size of the form. More settings equals more flexibility. If you have questions on what an individual item does, simply click the question mark next to it - as depicted in the image - and a description will appear.

Pre-Requisites: Make sure the template configured for this module instance has a <DetailTemplate> defined. DNN expects to link to the view of a single record. If no detail template is defined, the search integration will not work properly. For information on how to get the necessary values to display the details of a record, see the GUID item below.

Data Command: This is similar to the SQL you would use for your template's ListDataSource. It's purpose is to retrieve all the records for this module instance that you want indexed. You can use certain tokens like [[Portal:ID]] and [[Module:ID]] but, since the indexing process occurs outside a user session, you cannot use any user or session tokens like [[User:ID]].  Unlike ListDataSources though, you simply embed the tokens inside your SQL. You do not use <Parameter> tags. The tokens will be replaced at run-time. You cannot use field tokens here.

Title: This is the title that will be displayed for the record in the DNN search results page. You can mix and match text and field tokens to format the title.

Description: This will be displayed in the search results as the description/synopsis of the record. Use text and field tokens here to create the description. However, keep in mind that the end result must be 2000 characters or less. In other words the text plus the results of the processed field tokens can be no longer than 2000 characters.

Author ID: This one's optional. It should evaluate to a valid DNN User ID representing the record's author.

Content: This is the actual content you want to be indexed and searchable by your users. The same rules apply - use text and field tokens.

GUID: When search results are displayed, DNN will link create a link to that record's detail view. Please ensure that the module's template has a DetailTemplate defined. The GUID is what you can use to pass data into your detail template. When rendered, the GUID will become the URL parameters in the link. So, if your template displays a list of books, you might need the "BookID" to display details for a particular book. In that case, you would enter: bookid=[[BookID]] and your DetailDataSource would need to accept that parameter. The DetailDataSource's parameter, though, does not have to use the [[Url:bookid]] token to pull it in.  Here's an example of how the DetailDataSource may look:

<xmod:Template>
	...
	<DetailDataSource CommandText="SELECT * FROM Books WHERE BookId=@BookID">
		<Parameter Name="BookId" />
	</DetailDataSource>
	...
	<DetailTemplate>
		<strong>Author Name:</strong> [[FirstName]] [[LastName]]
	</DetailTemplate>
	...
</xmod:Template>

Last Modified Date: REQUIRED. This should evaluate to a valid date and time that represents when the record was last updated. It's an important field because DNN uses this value to evaluate whether the record needs to be re-indexed. If you use a value that doesn't change when the record is changed, the record will not be re-indexed and the old content will remain.

Search Key: A text value that uniquely identifies this record. Typically this may be the unique numeric ID that is assigned to a record. Search keys can be a maximum of 100 characters.  Note that the maximum length is the rendered length - after any field tokens have been processed.