Hyrax Introduction

Introduction

A Brief History of Hydra Applications

2012

Hydrangea

• complete UI
• no pre-determined model
• Hydra version 3

2013 - Sufia

• built as Penn State's institutional repository and published as a gem
• first app with a model
• file-based

2014 - Curate

• collaboration between Cincinnati, Notre Dame, UI, and Northwestern
• works-based

2015

• Curate was never fully realized
• morphed in to Worthwhile
• re-envisioned/rewritten as Curation Concerns (by Princeton)
• PCDM appears ... everyone gets on board
• Fedora 4 is released

2016

• Sufia and CC are the front-running applications
• Looked like this
• A merger is proposed
• Somebody gets an IMLS grant, and a box

2017

• Hydra is dead, long live Hydra!
• Hyrax is the base application for the project formerly known as, Hydra-in-a-Box

So, what is so great about Hyrax

It took us 5 years, but we think we might have it right this time.

• our best work yet
• Common place for all(?) hydra devs to collaborate (CC+Sufia)
• Multi-file works
• Polished UI
• Configurable
• Common target for pluggins
• Internationalized
• Never again will you ask, "Is this in Curation Concerns or Sufia?"

But, not so great

• still kinks
• 100% volunteer-driven

Anatomy of a Hyrax Stack

MVC, or rather CMV

A typical Rails application:

GET /foo
    |
    |
    controller => foos#new
    |
    |
    model => Foo.new
    |
    |
    view => renders HTML form
    |
    |
    helpers

The Hyrax Stack

Show view

Single resource from Fedora that has been indexed in Solr

GET /work/1
    |
    |
    authorization (CanCanCan gem, Ability class)
    |
    |
    controller => Works#show
    |
    |
    presenter => Presenter.new(SolrDocument, Ability)
    |
    |
    view => renders HTML form
    |
    |
    helper, renderers

Edit view

GET /work/1/edit
    |
    |
    authorization (CanCanCan gem, Ability class)
    |
    |
    controller => Works#edit
    |
    |
    model => Work.new
    |
    |
    form => (Form.new(work, Ability)
    |\
    | \-> SimpleForm inputs
    |
    view => renders HTML form
    |
    |
    helpers, inputs (SimpleForm)

Create and Update

POST /work/1
     |
     |
     authorization (CanCanCan gem, Ability class)
     |
     |
     controller => Works#create
     |
     |
     actors
        \
         \-> (FirstActor)  --> jobs
             (SecondActor) --> jobs
          |<-(ThridActor)  --> jobs
         /
       /
     view  => renders HTML form
     |
     |
     helpers, inputs (SimpleForm)

Class Details

Models

• define properties and their indexing
• sets an indexer class for custom indexing needs
• can do validations, but this often moved to the form or other UI elements

Controllers

• act as a switching station
• defines a model (curation concern type), presenter, form, search builder, and other elements

SolrDocumnet

• unique class to Hydra
• wraps a hash response from Solr to provide accessor methods or custom fields

Presenters

• takes a SolrDocument, Ability, and (sometimes) controler response
• encapsulates logic used to display content
• defines which fields are displayed
• enables a "Fedora-less" display layer
• presenters call other presenters: nested works, contained file sets

Forms

• equivalent to presenters - takes a model instead of SolrDocument
• interaction point between the controller and model
• defines which fields are in the edit form
• like presenters, also encapsulates display logic

Actors

• define a specific set of procedures or actions that would take place when a model is updated or created
• arranged in a stack, or array, that is always executed in the same order each time
• Examples: adding files to works, files to collections, and updating metadata
• custom procedures can be added by adding a new actor to the stack
• there is only one stack
• it's not a workflow

Jobs

• actions typically performed asynchronously, usually called by an actor
• ex: derivative creation, characterization, ingesting files

Services

• service object architecture: classes that generally only have one method call
• good for one-off things that would be called from a variety of different contexts
• ex: paths to files, anything NOT asynchronous
• similar to jobs but have a much smaller scope

Indexers

• come from AciveFedora
• encapsulate the instructions and processes needed create a solr document from a model
• typically contain one overridden method generate_solr_document

Stuff We Probably Won't Get To

• Search builders
• anything Javascript
• SimpleForm inputs
• Renderers
• Helpers