hydra-head 3.0.0pre1 → 3.0.0pre2

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    hydra-head (0.0.1)
+    hydra-head (3.0.0pre1)
       RedCloth (= 4.2.3)
       active-fedora (>= 2.3.3)
       blacklight (= 3.0.0)
@@ -81,6 +81,7 @@ GEM
       activemodel (= 3.0.9)
       activesupport (= 3.0.9)
     activesupport (3.0.9)
+    addressable (2.2.6)
     arel (2.0.10)
     blacklight (3.0.0)
       kaminari
@@ -139,7 +140,8 @@ GEM
     json_pure (1.5.3)
     kaminari (0.12.4)
       rails (>= 3.0.0)
-    launchy (2.0.3)
+    launchy (2.0.4)
+      addressable (~> 2.2.6)
     linecache (0.46)
       rbx-require-relative (> 0.0.4)
     logger (1.2.8)
@@ -149,10 +151,10 @@ GEM
       mime-types (~> 1.16)
       treetop (~> 1.4.8)
     marc (0.4.3)
-    mediashelf-loggable (0.4.2)
+    mediashelf-loggable (0.4.5)
     mime-types (1.16)
     mocha (0.9.12)
-    multipart-post (1.1.2)
+    multipart-post (1.1.3)
     nokogiri (1.5.0)
     om (1.2.5)
       nokogiri (>= 1.4.2)

data/HOW_TO_GET_STARTED.textile

@@ -0,0 +1,571 @@
+h1. Getting Started Building Your Own Hydra Application
+
+
+*!!! This is a WORK IN PROGRESS !!!*
+
+h3. What you will learn from this document:
+
+Set up a Hydra application (a rails app that uses the hydra-head plugin) and run it
+Define a new Content Type called JournalArticle
+# Define the ActiveFedora Model for JournalArticles
+# Index JournalArticles into solr
+# Customize how JournalArticles appear in search results
+# Define JournalArticles “show” view
+# Define JournalArticles “edit” view 
+
+h2. Set up a new Hydra Head
+
+See "README":http://hudson.projecthydra.org/job/hydra-head-rails3-plugin/Documentation/file.README.html for instructions on creating a new Hydra Head
+
+h3. Starting the App out of the Box
+
+h4. (1) Migrate the development databases.
+
+From the rails application root directory:
+
+<pre>
+  rake db:migrate
+</pre>  
+
+h4. (2) Start Jetty, pre-configured with Fedora and Solr
+
+_Stop any copies of jetty (or anything else using port 8983) before running this command._
+(Note that java 1.6 must be invoked by the "java" command or Fedora won't work.)
+
+<pre>
+  rake hydra:jetty:config 
+  rake hydra:jetty:start
+</pre>  
+
+This will start up a pre-configured jetty instance running Fedora and Solr on port 8983.
+
+Ensure Solr is running:  "http://localhost:8983/solr/development/admin":http://localhost:8983/solr/development/admin should show the Solr admin page.  You should be able to click on the Statistics link (or go to "http://localhost:8983/solr/development/admin/stats.jsp":http://localhost:8983/solr/development/admin/stats.jsp) and there should be more than 0 documents in the index if you loaded the features properly.  Or look for documents in "http://localhost:8983/solr/development/select?q={!defType=dismax}*:*"http://localhost:8983/solr/development/select?q={!defType=dismax}*:*
+
+Ensure Fedora is running:  "http://127.0.0.1:8983/fedora/describe":http://127.0.0.1:8983/fedora/describe should show the Fedora Repository Information View.  The following query should return objects:  "http://localhost:8983/fedora/objects?pid=true&title=true&terms=&query=&maxResults=20":http://localhost:8983/fedora/objects?pid=true&title=true&terms=&query=&maxResults=20
+
+h4. (2.5) Import some Sample Content (other than fixtures??)
+
+h4. (3) Start the Rails Application
+
+<pre>
+  rails server
+</pre>  
+
+To ensure the rails app is running, go to "http://localhost:3000/":http://localhost:3000/
+
+h3. Ensure your Hydra App is set up properly
+
+Run cucumber tests ... except they are for test, not development environment ...
+
+h4. Import the Fixture/Test Objects
+
+Grab the test/fixture objects that the hydra-head gem's tests rely on.  These objects are useful for getting a sense of how hydra works, but you will want to delete them later and create your own 
+fixtures to run your application's tests against.
+
+First, use the hydra:hyhead_fixtures generator to put the fixture xml files into test_support/fixtures
+
+<pre>
+  rails g hydra:hyhead_fixtures
+</pre>
+
+Now use the hydra:fixtures:refresh rake task to import the fixtures into Fedora and Solr
+
+<pre>
+  rake hydra:fixtures:refresh RAILS_ENV=test
+</pre>
+
+If you want to see the fixture objects in your development environment, run the rake task again without RAILS_ENV set.
+
+<pre>
+  rake hydra:fixtures:refresh 
+</pre>
+
+h4. Run the Hydra-Head gem's RSpec Tests
+
+<pre>
+  rake hyhead:spec
+</pre>
+
+This will print out a lot of information while the tests run.  If all the tests passed, you will see something like this (the important part is "0 failures"):
+
+<pre>
+  ...
+  Finished in 22.53 seconds
+  240 examples, 0 failures, 19 pending
+</pre>
+
+h4. Run the Hydra-Head gem's Cucumber Tests
+
+Before running the cucumber tests, you have to remove the default index.html file that Rails provides
+
+<pre>
+  rm public/index.html
+</pre>
+
+Now run the cucumber tests
+
+<pre>
+  rake hyhead:cucumber
+</pre>
+
+This will print out a lot of information while the tests run.  If all the tests passed, you will see something like this (the important part is that the number of scenarios equals the number of tests passed):
+
+<pre>
+  37 scenarios (37 passed)
+  215 steps (215 passed)
+  0m45.591s
+</pre>
+
+h3. Exploring what comes out of the box
+
+* log in, create sample account
+* use facets
+* run a search
+* look at one of the sample objects
+* edit one of the sample objects
+* create a new MODS article …
+* upload a file …
+* change the permissions on the new article, making it visible to the public (before setting permissions, prove that you can’t see it when logged out, then change permissions, log out again & prove that it’s visible)
+
+
+h2. Making local changes to your Hydra Application
+
+In order to make it easy to get any new functionality added to the hydra stack (see "README":http://hudson.projecthydra.org/job/hydra-head-rails3-plugin/Documentation/file.README.html), while retaining your Hydra application's localizations, your local hydra application code should be set up to override the upstream Hydra stack code. 
+
+Luckily, rails engines has made this easy - the Hydra code is organized so your localizations are kept separate from the core hydra application code.
+
+Moreover, to ensure your localizations won't be broken by upgrading the Hydra core code, we STRONGLY recommend that you write tests for every local change you make.  This will allow you to ensure that upgrading the core code doesn't break any local changes you have made.
+
+So, two key points:
+
+<b>
+# always write tests for your local modifications
+# always change code at the app level, and never change anything in vendor/plugins.
+</b>
+
+"INITIAL_APP_MODS":http://hudson.projecthydra.org/job/hydra-head-rails3-plugin/Documentation/file.INITIAL_APP_MODS.html explains how to make two basic changes to your hydra rails application and how to write the appropriate tests for them.
+
+
+h2. The new Content Type: JournalArticle
+
+In this tutorial, we are creating a new JournalArticle content type.  This will allow us to create Journal Articles in a Fedora Repository, collect custom metadata for them, index them in solr, and display that custom metadata in the user interface.
+
+In order to describe our Fedora objects, we can use whatever metadata schemas suit our needs.  Some metadata schemas currently being used in Hydra Heads include MODS, Dublin Core, EAD, PBcore, EAC-CPF and VRE.  This list continues to grow as people set up Hydra Heads to deal with their own specialized content.
+
+The JournalArticle content type will use MODS (handily available in hydra-head) to track descriptive metadata about Articles.  Some of the metadata is common to many types of content:
+
+* title
+* author (first name, last name, role)
+* abstract
+
+Other metadata fields are more specifically relevant to journal articles, but they still fit into the MODS schema:
+
+* journal title
+* publication date
+* journal volume
+* journal issue
+* start page
+* end page
+
+In addition to the MODS metadata, JournalArticle objects will use Hydra Rights Metadata to track information about licenses, rights, and which people/groups should be able to discover, view, and/or edit each Journal Article.
+
+h2. Define the ActiveFedora Model for JournalArticles
+
+The first thing to do when adding a new content type is to create the ActiveFedora Model.  This model is a Ruby class that uses ActiveFedora to tell the application the structure of your content and its metadata.
+
+The model we create can be used in any application with ActiveFedora and OM (Opinionated Metadata), not just in a Hydra Head.  For example, ActiveFedora models can be used in batch scripts, command line utilities, and robots that perform automated actions on your fedora objects based on information and behaviors stored in their ActiveFedora models.
+
+h4. Where to find the full tutorial on defining ActiveFedora Models
+
+This tutorial will only cover the very basics of defining an ActiveFedora Model and defining OM terminologies for its XML datastreams.  For a complete introduction to those topics, see the  "ActiveFedora Console Tour":http://hudson.projecthydra.org/job/active_fedora/Documentation/file.CONSOLE_GETTING_STARTED.html and the tutorials included in the "OM documentation":http://hudson.projecthydra.org/job/om/Documentation/.
+
+h3. Tests to Define Expected Behaviors
+
+(<b>MUST HAVE EXAMPLES HERE PERTINENT TO EXPECTED JOURNAL ARTICLE BEHAVIORS</b>)
+
+h4. Run the tests
+
+The test code should execute but the tests should fail because we haven't written the code yet.
+
+h3. Defining the Datastreams
+
+A Fedora object is made up of any number of _datastreams_.  Datastreams can have content of any type and each datastream is identified by a _datastream id_ or _dsid_.  The ActiveFedora model tells us which datastreams to expect or create in an object and tells us what kind of content is expected inside each datastream.
+
+For our JournalArticle model, we're particularly interested datastreams with XML content because a JournalArticle object is basically a container for XML metadata.  The actual content of the Article (PDF,text,whatever.) will be stored in a separate Fedora object, a _primitive_, with the RDF isPartOf relationship connecting the JournalArticle (primarily metadata) to its content (any number of primitives with files in them).  For more information about datastreams, primitives, and where the actual content of an object lives, see the Reference links at the end of this tutorial.
+
+h3. descMetadata -- the Descriptive Metadata Datastream
+
+Our MODS xml will go into a datastream with the datastream id of _descMetadata_.  Technically, we could give it any name we want but the Hydra community has come up with some conventions to make things simpler.  One of these conventions is to always put descriptive metadata in a datastream called descMetadata.
+
+As we said above, we want to create MODS metadata that keeps track of title, author (first name/last name/role), publication date, abstract, journal title, journal volume, journal issue, start page and end page.  In order to do this we will use ActiveFedora to define a special type of Ruby object that uses OM to read and modify XML.
+
+Example of the MODS XML we will be creating:
+
+<pre>
+<mods xmlns="http://www.loc.gov/mods/v3" version="3.0"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/mods/v3
+     http://www.loc.gov/standards/mods/v3/mods-3-0.xsd">
+   <titleInfo>
+       <title>ARTICLE TITLE</title>                                   <!-- title -->
+   </titleInfo>
+   <name type="personal">
+       <namePart type="family">FAMILY NAME</namePart>                 <!-- author last name -->
+       <namePart type="given">GIVEN NAMES</namePart>                  <!-- author first name -->
+       <role> 
+           <roleTerm authority="marcrelator" type="text">Creator</roleTerm> <!-- author role -->
+       </role>
+   </name>
+   <abstract>ABSTRACT</abstract>                                    <!-- abstract -->
+   <relatedItem type="host">
+       <titleInfo>
+           <title>TITLE OF HOST JOURNAL</title>                     <!-- journal title -->
+       </titleInfo>
+       <part>
+           <detail type="volume">
+               <number>2</number>                                   <!-- journal volume -->
+           </detail>
+           <detail type="level">
+               <number>2</number>                                   <!-- journal issue -->
+           </detail>
+           <extent unit="pages">
+               <start>195</start>                                   <!-- start page -->
+               <end>230</end>                                       <!-- end page -->
+           </extent>
+           <date>FEB. 2007</date>                                   <!-- publication date -->
+       </part>
+    </relatedItem>
+</mods>
+</pre>
+
+The constraints of a metadata schema sometimes force us to put information into structures that don't map directly to the vocabulary that we use when talking about that information.  The "title" has ended up in a spot that you might call the "mods titleInfo title" and the "start page" has ended up in a spot that you might call the <pre>"mods host-relatedItem part pages-extent start"</pre> or <pre>"//mods/relatedItem[@type=host]/part/extent[@unit='pages']/start"</pre> ... quite the mouthful, isn't it?  This is where OM comes in.  OM lets us define a Terminology that will allow us to access values in the xml based on our natural vocabulary (title, start page, etc.) while also allowing us to access those same values using the more cumbersome XML-speak when necessary.
+
+h4. WRITE TESTS HERE!  (for the expected behaviors of a descMetadata datastream model?)
+
+specs to test model?  features?
+
+h4. Coding the descMetadata Datastream model
+
+Here's how we define the datastream class for the descMetadata.  Notice that we use set_terminology which defines its OM Terminology.  
+
+<b><i>Create a new file in app/models called journal_article_mods_datastream.rb</i></b> and put this into it (NOTE: you could also save this file as lib/journal_article_mods_datastream.rb and get the same results):
+
+<pre>
+# a Fedora Datastream object containing Mods XML for the descMetadata 
+# datastream in the Journal Article hydra content type, defined using 
+# ActiveFedora and OM.
+
+class JournalArticleModsDatastream < ActiveFedora::NokogiriDatastream
+
+  # OM (Opinionated Metadata) terminology mapping for the mods xml
+  set_terminology do |t|
+    t.root(:path=>"mods", :xmlns=>"http://www.loc.gov/mods/v3", :schema=>"http://www.loc.gov/standards/mods/v3/mods-3-2.xsd")
+    t.title_info(:path=>"titleInfo") {
+      t.main_title(:index_as=>[:facetable],:path=>"title", :label=>"title")
+    }
+    t.author {
+      t.first_name(:path=>"namePart", :attributes=>{:type=>"given"})
+      t.last_name(:path=>"namePart", :attributes=>{:type=>"family"})
+      t.role {
+        t.text(:path=>"roleTerm",:attributes=>{:type=>"text"})
+      }
+    }
+    t.abstract 
+    t.journal(:path=>'relatedItem', :attributes=>{:type=>"host"}) {
+      t.title_info(:ref=>[:title_info])
+      t.issue(:path=>"part") {
+        t.volume(:path=>"detail", :attributes=>{:type=>"volume"}, :default_content_path=>"number")
+        t.level(:path=>"detail", :attributes=>{:type=>"number"}, :default_content_path=>"number")
+        t.pages(:path=>"extent", :attributes=>{:unit=>"pages"}) {
+          t.start
+          t.end
+        }
+        t.date
+      }
+    }
+      
+    # these proxy declarations allow you to use more familiar term/field names that hide the details of the XML structure
+    t.title(:proxy=>[:title_info, :main_title])
+    t.start_page(:proxy=>[:journal, :issue, :pages, :start])
+    t.end_page(:proxy=>[:journal, :issue, :pages, :end])
+    t.publication_date(:proxy=>[:journal, :issue, :date])
+
+  end # set_terminology
+
+end # class
+</pre>
+
+This will allow you to access the metadata values like this when dealing with a JournalArticleModsDatastream object:
+
+<pre>
+  ds.term_values(:author, :first_name)
+  ds.term_values(:start_page)
+  ds.term_values(:journal, :issue, :pages, :start)  # same result as the previous line, but more detailed reference to the xml node
+</pre>
+
+<b>(CAN WE DO TESTING NOW?  OR DO WE NEED TO DEAL WITH THE ENTIRE FEDORA OBJECT BEFORE TESTING?)</b>
+
+h3. rightsMetadata -- The Hydra Rights Metadata Datastream
+
+The hydra-head plugin provides a class definition for the rightsMetadata datastream, so you won't have to define the OM Terminology yourself.  The definition is in the hydra-head plugin code in "lib/hydra/rights_metadata.rb":https://github.com/projecthydra/hydra-head/blob/master/lib/hydra/rights_metadata.rb.
+
+Here's an example of what rightsMetadata XML looks like:
+
+<pre>
+  <rightsMetadata xmlns="http://hydra-collab.stanford.edu/schemas/rightsMetadata/v1">
+      <copyright>
+        <human>(c)2009 The Hydra Project</human>
+        <human type="someSpecialisedType">Blah Blah</human>
+        <human type="aDifferentType">More blah</human>
+    		<machine><a rel="license" href="http://creativecommons.org/licenses/publicdomain/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/publicdomain/88x31.png" /></a><br />This work is in the <a rel="license" href="http://creativecommons.org/licenses/publicdomain/">Public Domain</a>.</machine>
+  	</copyright>
+  	<access type="discover">
+  		<human></human>
+  		<machine>
+  			<policy>hydra-policy:4502</policy>
+        <group>public</group>
+      </machine>
+  	</access>
+  	<access type="read">
+  		<human></human>
+  		<machine>
+        <group>public</group>
+      </machine>
+  	</access>
+  	<access type="edit">
+  		<human></human>
+  		<machine>
+  		  <person>researcher1</person>
+        <group>archivist</group>
+  		</machine>        
+  	</access>
+    <access type="etc">
+            <!-- etc -->
+    </access>
+  	<use>
+  		<human>You are free to re-distribute this object, but you cannot change it or sell it. </human>
+  		<machine><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-nd/3.0/us/88x31.png" /></a><br />This <span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Sound" rel="dc:type">work</span> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/">Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License</a>.</machine>
+  	</use>
+
+  </rightsMetadata>
+</pre>
+
+h3. RELS-EXT & DC Datastreams (Fedora defaults)
+
+There are two special datastreams that Fedora creates for you -- the DC datastream and the RELS-EXT datastream.  We don't really use the DC datastream.  It contains simple Dublin Core metadata that mainly exists for Fedora's internal use.  The RELS-EXT datastream contains RDF representing the relationships between the objects in a Fedora repository.  ActiveFedora and Hydra both use these RDF relationships in a number of ways.  For more information about how to work with RDF relationships in ActiveFedora, see the ActiveFedora documentation links at the end of this tutorial.
+
+h2. Defining the Model and adding the Datastreams to it
+
+<b><i>Create a file in app/models called journal_article.rb</i></b> and put these lines into it:
+
+<pre>
+# a Fedora object for the Journal Article hydra content type
+class JournalArticle < ActiveFedora::Base
+  include Hydra::ModelMethods
+  
+  has_metadata :name => "descMetadata", :type=> JournalArticleModsDatastream
+  has_metadata :name => "rightsMetadata", :type => Hydra::RightsMetadata
+end
+</pre>
+
+<b>(CAN WE DO TESTING NOW?)</b>
+
+
+h2. Test Your Work
+
+<b>THE TESTS WE WROTE ABOVE SHOULD PASS NOW ...</b>
+
+(specs?  if features ... jetty must be running?)
+
+h2. Loading your new Model in the Rails App
+
+If you have put the new files you've created into app/models and/or the lib directory, then they will be automatically loaded by the application when you run it using script/server or script/console.
+
+h2. Creating new JournalArticle Objects
+
+Start up Fedora and Solr on port 8983, assuming they are not already running:
+
+<pre>rake hydra:jetty:start</pre>
+
+Create a JournalArticle object using the console (rather than from the UI of the rails app)
+
+<pre>script/console</pre>
+
+Type these lines at the console command line:
+
+<pre>
+  article = JournalArticle.new
+  article.save
+  # In case you're curious, explore a bit...
+  article.pid
+  article.datastreams.keys
+  article.datastreams["descMetadata"].class
+  article.datastreams["rightsMetadata"].class
+  article.relationships
+</pre>
+
+h2.  Getting metadata into JournalArticle Objects
+
+h2. Index JournalArticles into Solr
+
+By default, ActiveFedora automatically updates Solr whenever you save an object to Fedora.  If you want to re-index it, all you have to do is load an instance of the object and call its update_index method.  For example, if you wanted to update an object that has a pid "changeme:30", you could do it like this:
+
+<pre>
+  article = JournalArticle.load_instance("changeme:30")
+  article.update_index
+</pre>
+
+In reality, when you want to re-index an object in Solr, you should use Solrizer.  Solrizer is specifically designed to help you keep your solr indexes up to date.
+
+"Solrizer Documentation":http://hudson.projecthydra.org/job/solrizer/Documentation/
+
+"Solrizer on GitHub":https://github.com/projecthydra/solrizer
+
+Solrizer is able to figure out how to index XML based on the OM Terminologies you've defined.  It defaults to indexing nearly everything in generic ways, but there are many ways to customize this behavior. See the "Solrizer Documentation":http://hudson.projecthydra.org/job/solrizer/Documentation/ for more information about how it works.
+
+h2. Basic Access Controls
+
+The access controls in the hydra-head plugin work on the assumption that you will put your access controls information into a datastream called rightsMetadata and then index the values from that datastream into Solr.  The plugin provides all the tools that you need in order to do this.  Most of the work is handled for you by this line in your model:
+
+<pre>
+  has_metadata :name => "rightsMetadata", :type => Hydra::RightsMetadata
+</pre>
+
+The plugin defaults to *denying access* when the permissions are unclear.  This means that in cases where there is no rightsMetadata datastream or the information in the datastream is unclear or incomplete, the Hydra head will act like the object does not exist.  _The object will not show up in search results and you will not be able to view it._
+
+To give yourself permission to view and edit an object, you need to set those permissions.  For example, if we want the object to show up in search results for everyone but we only want a user called archivist1 to edit it, we can do the following:
+
+<pre>
+  article = JournalArticle.load_instance("changeme:30")
+  article.permissions({"group"=>"public"}, "read")
+  article.permissions({"person"=>"archivist1"}, "edit")
+  article.save
+</pre>
+
+hydra-head provides you with tools to expose a permissions editor to your end-users.  This allows them to control who can discover/read/download/edit the objects they create.
+
+h2. Logging into the Hydra Head and creating a User Account
+
+Blacklight & the hydra-head plugin provide a basic user authentication that is meant to be replaced by code that connects to your institutional authentication system like LDAP or Shibboleth.  While setting up this sample hydra-head, you need to create user accounts in that system.  To do this, run the application, visit http://localhost:3000 and click on "login" then click on "create an account" below the login form.  
+
+In thes sample above, we gave "edit" permissions to a user called "archivist1", so create an account with that login id.  Choose whatever email & password you want.  Now you can log in as that user when you want to test features that require you to be logged into the hydra head.
+
+h2. Defining Custom Views
+
+Now that you've created a couple objects and indexed them, you can view them in the application.  Remember, _objects will not show up in search results unless the permissions are set properly in rightsMetadata_.
+
+h3. Add a link to create an Article
+
+First, we need to add a link to the Hydra Head that lets you create Journal Articles.  To do this, you need to override the _add_asset_links view partial.  Here's the cucumber test for what you want:
+
+<pre>
+  Feature: Button to Add Articles
+    In order to create Journal Articles
+    As a person with submit permissions
+    I want to see a button for adding articles
+
+    Scenario: button to add articles on home page
+      Given I am logged in as "archivist1"
+      When I am on the home page
+      Then I should not see "Add a MODS Asset"
+      And I should see "Add an Article"
+</pre>
+
+hydra-head puts a list of "add asset" links into the user_util_links section of the page.  This list is defined in app/views/_add_asset_links.html.erb. By default, this list includes links for adding Images, MODS Assets and Generic Content.  We want it to have just one link -- create an Article.  To override the list, create a file at app/views/_add_asset_links.html.erb and put this into it:
+
+<pre>
+  <div id="select-item-box">
+    <ul id="select-item-list">
+      <li>
+        <%= link_to_create_asset 'Add an Article', 'journal_article' %>
+      </li>
+    </ul>
+  </div>
+</pre>
+
+Now start your application and visit http://localhost:3000
+
+h3. Default Views
+
+
+JournalArticles will show up with the default views until you create custom views for that content type
+
+search results, facets
+detail & edit views
+
+h3. Customize how JournalArticles appear in search results
+
+h3. Change the Search Result Headings
+
+h3. Define JournalArticles “show” view
+
+
+h3. Define JournalArticles “edit” view
+
+
+displaying MODS edit
+rednering permissions_edit views
+rendering file uploader
+
+h3. The File List
+
+
+-- show & edit
+
+h2. Access Controls (Example)
+
+
+Create an object, edit permissions, see that permissions have changed.
+
+h2. Miscellaneous
+
+
+* Adding a Facet
+* Link to info on overriding styling
+* Overriding Helpers
+
+
+h2. Reference
+
+
+h3. Documentation & More Tutorials
+
+h4. API Docs
+
+ActiveFedora API Docs
+OM API Docs
+
+h4. Tutorials
+
+"ActiveFedora Console Tour":http://hudson.projecthydra.org/job/active_fedora/Documentation/file.CONSOLE_GETTING_STARTED.html
+"OM-based NokogiriDatastreams":http://hudson.projecthydra.org/job/active_fedora/Documentation/file.NOKOGIRI_DATASTREAMS.html
+"OM Documentation":http://hudson.projecthydra.org/job/om/Documentation/
+
+h3. Hydra Modeling Conventions
+
+
+h4. Reference info on the Hydra Wiki
+
+
+"Hydra objects, content models(cModels) and disseminators":https://wiki.duraspace.org/display/hydra/Hydra+objects%2C+content+models+%28cModels%29+and+disseminators
+
+"Don’t Call it a Content Model":https://wiki.duraspace.org/display/hydra/Don%27t+call+it+a+%27content+model%27%21
+
+h4. genericContent cModel
+
+* descMetadata (required): Descriptive Metadata like MODS or DC.  MODS is recommended
+* rightsMetadata (recommended): Rights, License, and Permissions information.  Hydra rightsMetadata XML is recommended.
+h4. Understanding Parts (Where will my uploaded files go?)
+
+h5. Primitives contain actual files
+
+bq. A primitive is a fundamental atom object that bears an actual file payload. They are single, (near-) universal content types which may either stand-alone or be incorporated into higher order content types (in a book or ETD, e.g.).
+
+h5. Higher Level Objects
+
+bq. Higher Level Objects represent higher-level, molecular objects that may have primitives and/or other Higher-level objects as children.
+
+h5. Relationships
+
+"isPartOf":info:fedora/fedora-system:def/relations-external#isPartOf -- Hydra reserves this predicate for use in representing part-whole relationships between objects.  This occurs most often when representing which Primitives (ie. an uploaded PDF) are _part_ of a Higher Level object (ie. a MODS Article)
+
+
+h3. How to Add a New Facet