Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out a hook system for indexing data from other plugins #8

Closed
erochest opened this issue Apr 11, 2012 · 5 comments
Closed

Figure out a hook system for indexing data from other plugins #8

erochest opened this issue Apr 11, 2012 · 5 comments
Assignees
Milestone

Comments

@erochest
Copy link
Contributor

Right now, this supports TEI Plugin and Fedora Connector, but both are hard-coded. This should be replaced by a hook system to any plugin can submit data for the document when it's being indexed.

@waynegraham
Copy link

Actually this a bit bigger an issue than just TEI & Fedora; plugins like SimplePages and ExhibitBuilder also should be indexed (or at least one would have the expectation that they would) when they do a search. I think at a minimum, we need to figure out how to handle the plugins that ship with Omeka that generate content and move on form there.

@erochest
Copy link
Contributor Author

erochest commented May 2, 2012

Here's my understanding of our discussion of the solution. Feel free to correct me:

Under SOLR_SEARCH_PLUGIN_DIR will be a new directory that contains configuration files for other plugins. Each configuration file will most likely be an INI file, but I may have to use a DSL.

The configuration files will specify other entities to index and search. These will be defined by the tables and columns to use for the Solr fields.

We'll also add a new standard facet, Result Type. Search plugins (or whatever we're calling these) can define a facet value for Result Type for the items that they define. Items will be included in this with the field value "Item".

Example Config File

Here's a sample config file for the Exhibits plugin. The real one will contain more entries for Sections, etc.

; Sections without dots are main sections.
[Exhibits]
; The column to pull the ID from. This defaults to 'id'.
id_column=id
; The facet value for "Result Type"
result-type=Exhibits
; For the moment, I'm restricting this to one table, but I'm open to convincing...
table={$prefix}_exhibits
; Optional
flag=public
; Optional, will also index the taggings, if the entity is taggable.
tagged=yes

; Sections with dots are in the form SECTION.COLUMN.
[Exhibits.title]
; A name, just in case. I expect it will really only be used for facets.
name=Exhibit Title

[Exhibits.description]
name=Exhibit Description

[Exhibits.featured]
name=Featured Exhibit
; If given and truthy, this will be used as a facet.
facet=yes

@jeremyboggs
Copy link
Member

So in your example, you'd add a separate section for Exhibit Pages?

@erochest
Copy link
Contributor Author

erochest commented May 2, 2012

Exactly. And they'd be separate Result Types also (if defined that way).

@ghost ghost assigned erochest May 2, 2012
@erochest
Copy link
Contributor Author

erochest commented May 3, 2012

Mocking up some options for config at https://gist.github.com/2586346

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants