On 1/3/06, Tim L. firstname.lastname@example.org wrote:
I see in the API docs it says to make the index calls from the
controller. Would it not be better to do it from an ActiveRecord
Good question. I thought about that - and in fact, in my first pass
at this it’s what I did. The problem I have with that approach is
that you then have to have knowledge of URIs in the ActiveRecord
classes, and that seemed to break the MVC paradigm.
It was also problematic when a single view had several different
active records in it. For example, a single view that contains course
and instructor records for a university administration system may get
that data from two different active record types. If you put the
calls to the indexer in the ActiveRecord classes, you then have to
make multiple calls to the indexer (one from each type). The
controller is typically aware of both anyway, so it seems to make more
When content is indexed, the indexer wants the content, the title, and
a URI to access the content, supplied via IndexableRecord::IndexData
To index multiple objects as a part of a single view, you can
concatenate the content from each active record, but still only
provide a single URI and title.
Of course, there’s nothing stopping you from doing it with an
observer. The API doens’t care if it’s called from the controller or
an active record. Just add “include IndexedSearchEngine” to your
class. Having the calls to the controller is just the convention that
I settled on for the reasons noted above.