collective/Products.PloneGlossary — pull request #5 by mauritsvanrees (2013-12-21 00:18:14+00:00)
Title: Support dexterity by generalizing getting SearchableText. Also: show the portlet less often.

Currently, PloneGlossary can highlight terms in dexterity content just fine, but there is a restriction: only terms in the title and description are found, because that is what `SearchableText` in CMFDefault returns. Dexterity itself does not define a `SearchableText` method. If those terms are found in the text field of a dexterity page, they are highlighted, but terms that occur *only* in the text field are not highlighted.

In the first commits of this pull request I experimented with iterating over text fields of dexterity content, in a way similar to what we already do for Archetypes content. But in the end I settled for one clean method for all content: basically get the `plone.indexer` wrapper for the content and ask it what it would store in the catalog for the SearchableText index. We fall back to simply calling `SearchableText`, as usual.

This seems to work fine for both Archetypes and dexterity. Specifically, dexterity content from `plone.app.contenttypes` has its own special indexers for `SearchableText` that know for each portal_type which fields should be added. If you add `collective.dexteritytextindexer` to the eggs of your buildout, you can enable the 'Dynamic SearchableText indexer behavior' for your custom dexterity content types. Then you can edit your model definition through the web or in an xml or python file to mark some fields as searchable, and the indexer defined in `collective.dexteritytextindexer` will index it just fine. The best sample xml model definition is from the document content type in `plone.app.contenttypes`, where `indexer:searchable` is the important part that marks a field as searchable:

```

False

Text

```

A possibly nasty side effect of this pull request is that this way of getting the searchable text also works on files, so it returns the text converted to plain text. In other words, when viewing a pdf file this will call `pdftotext` or some similar command, which may take more time than wanted, and seems a waste. The strong suggestion here is to disable highlighting on files. This is also the default.

This does mean that we need a change to the portlet logic. Currently, if you add a glossary portlet for showing the definitions, PloneGlossary always gets the SearchableText of the context and looks for terms there. This pull request changes the logic: if terms are not highlighted in the content area of a portal_type, do not show the definitions in a portlet either. This is a change. I can imagine that some people have turned off highlighting in a portal type and use the portlet to show the definitions anyway. There may be a use case for that, and this pull request breaks that use case. I don't mind, but if wanted, I could add some configuration to enable that use case again.