Feature Request : Field setting to restrict search indexing

[sbrickey]

using the SampleSite as an example, the Readings column should not be indexed.

[sbrickey]

temporarily, I've discovered that a column can be excluded, if it is marked as a 'Summary' column, as long as it's not the FIRST summary column.

This is because the TextContentConverter (used by the search indexing process to "read" data from a folder) captures the Title by using the Schema.GetSummarizeColumn() method, which looks for the FIRST field marked as 'Summary', and captures the Body by IGNORING any column marked as 'Summary'.

The ASSUMPTION is that a content type would only have one "summary" column, which the search should include as "Title", while all other fields would be considered "Body".

[sbrickey]

I would also like to add to this...

if it is known which fields SHOULD be indexed, of a given content type... and the search settings indicate which folders (and therefore which content types) WILL be indexed...

I would like to see the Kooboo indicate to Lucene the different content types... including the fields (that SHOULD be indexed) and their field values.

Then, in the QUERY API, search ALL of the indexed fields INDEPENDENTLY (instead of JUST using a title and concatenated body field).

PRESUMABLY, extra field hits would improve its rankings in the results..

but more importantly, there are two new ways to handle search results...

• as before, concatenate the per-field results for "basic" search results
• or, for specific content types, a template can be defined that handles rendering of that type of content... perhaps a "Link" content type should just render an <A HREF... >.

currently, the concatenation of Body fields makes the highlighting of results across multiple fields very tricky... and can be confusing if the fields are unrelated (ie: search for '0' from the SampleSite template can return articles with 0 readings... or, searching for 'ipsum' can return the body of the blog post followed by a 0 (number of readings), which is again confusing)

I am aware that such an effort is a MAJOR overhaul to the way that Kooboo performs its indexing and searching... perhaps it'd be possible to isolate the current behavior into its own "default search" module, with this approach as an "advanced search" replacement module?