Use the ResourceForm for FileSets

[marrus-sh]

This PR makes the following changes (in the interest of resolving the remaining issues with #5575) :—

• It refactors work‐specific form behaviours into a new class, Hyrax::Forms::PcdmObjectForm, to enable Hyrax::Forms::ResourceForm to be used with resource types other than PCDM objects @ 5c48b30. [Note №1]
• It moves FileSet metadata into a new YAML‐based configuration, file_set_metadata, and updates the model and form to both use the same metadata (previously the model used basic_metadata, and the form had hardcoded fields) @ f700452. [Note №2]
• It modifies Hyrax::Forms::FileSetForm to inherit from Hyrax::Forms::ResourceForm, with the intention of inheriting the lease and embargo handling behaviours provided there @ f63ca9c.
• It uses the form, instead of the model object directly, in the FileSet edit view, to allow embargo information to be populated in a Valkyrie context @ d0b785e.

Notes:

1. Hyrax::Forms::ResourceForm(…) now returns a class subclassing Hyrax::Forms::PcdmObjectForm, not Hyrax::Forms::ResourceForm directly. This is a bit awkward and confusing, but it preserves backwards‐compatibility with existing Hyrax applications which defined their models using the recommended class MyObjectForm < Hyrax::Forms::ResourceForm(MyObjectForm) syntax.

   FileSet forms (and other future forms which want to use the ResourceForm embargo/lease implementations but do not have PCDM object properties) consequently cannot use the function‐call syntax and should just subclass Hyrax::Forms::ResourceForm directly.

   See commit 5c48b30.

2. Hyrax::FileSet formerly included Hyrax::Schema(:basic_metadata) in the model, but had a more limited set of metadata actually exposed through the Hyrax::FileSetForm. The two furthermore did not agree on license, in that it is optional in basic_metadata but was required in Hyrax::FileSetForm.

   I’ve resolved this by creating a new metadata YAML, file_set_metadata, with just the attributes listed in the form or required by tests, and license set to required. But another solution might be to keep the full basic_metadata schema and allow license to be optional. See

   hyrax/lib/hyrax/specs/shared_specs/hydra_works.rb

   Lines 252 to 260 in bd2bcff

   	RSpec.shared_examples 'a Hyrax::FileSet' do
   	subject(:fileset) { described_class.new }
   	let(:adapter) { Valkyrie::MetadataAdapter.find(:test_adapter) }
   	let(:persister) { adapter.persister }
   	let(:query_service) { adapter.query_service }
   	it_behaves_like 'a Hyrax::Resource'
   	it_behaves_like 'a model with core metadata'
   	it_behaves_like 'a model with basic metadata'

   which implies general basic_metadata support, but not all attributes are tested and compare also 792ccfd which removed that requirement for collections considering that those attributes were never exposed in forms.

   (The attributes required by it_behaves_like 'a model with basic metadata' but not previously exposed on the form are: abstract, label, relative_path, resource_type, rights_notes, rights_statement, and source. If we’re comfortable revising this test, we could probably drop those from file_set_metadata.yaml.)

   By “form” I mean in a Reform/Hyrax::ChangeSet sense; the actual Edit page only has a field for title. That leaves open the question of which, if any, of these attributes actually need to be defined on the FileSet model?

   In the long term, I would like for the FileSet metadata to be configurable, but it’s hardcoded to whatever is in the YAML file for now.

   See commit f700452.

[jeremyf]

Can you talk a bit more about the desire for configurable FileSet metadata? I ask because this may drift the file_set towards a conceptual work.

Could these configurable attributes be better modeled in a work?

[no-reply]

@jeremyf i'm not sure that i see that making FileSet metadata configurable changes FileSet's status. couldn't this configuration help us move away from the work-like description in the BasicMetadata we use now?

[marrus-sh]

@jeremyf as far as this PR is concerned, @no-reply is right in that the changes here move the FileSet away from a conceptual work, in that the model used to use the same metadata as works (:basic_metadata) and now uses different metadata (which will hopefully be more limited).

as far as my personal desire for configurable metadata is concerned, this is of course open to discussion :) . mostly, though, i think it is a gut feeling deriving from the large number of attributes already present on the FileSet model—if FileSet only included :core_metadata, i wouldn’t necessarily be asking for additional configurability, but considering it currently contains a number of additional properties beyond just :core_metadata, i feel like those properties should be configurable.

none of that configurability is in this PR, though.

[no-reply]

@jeremyf do you have any thoughts about a path to move this one through?

[jeremyf]

I think this looks great and the docs and conversation help better understand what's happening!