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

Use case - Media gallary - describe ones, add multiple photos/media #1032

Open
Natkeeran opened this issue Feb 21, 2019 · 6 comments
Open

Use case - Media gallary - describe ones, add multiple photos/media #1032

Natkeeran opened this issue Feb 21, 2019 · 6 comments
Labels
Type: use case proposes a new feature or function for the software using user-first language.

Comments

@Natkeeran
Copy link
Contributor

Natkeeran commented Feb 21, 2019

Title (Goal) Media gallary - describe ones, add multiple photos/media
Primary Actor user, contributor to the repository
Scope Drupal
Level Medium
Story I am a user/contributor. I have a set of photographs taken at an event. I would like to describe the metadata once and upload multiple photographs related to that event. I would like to have the option of adding different titles/alt tags and description for the different photographs.

Currently, drupal provides field formatters to display multiple files as a gallery. In CLAW, we can upload any number of files associated with a repository item. However, derivative workflow and display logic expect that only one image/video/audio will be associated with one repository item.

@dannylamb
Copy link
Contributor

I've been waiting for this one. So far we've been one file per media, with the assumption that it's one media being described. But it's 100% legit in Drupal to have more than one file per Media, or more than one Media as "Original Files", so we need to sort all that out.

This really feels like we're searching for the convention we need for Compound objects.

@seth-shaw-unlv
Copy link
Contributor

This brings up the old atomistic v. compound object debate. Do we want a single aggregate metadata record for multiple files (what is suggested here) or do we want each file to have a metadata record for each object component (e.g. the book module solution @rangel35 is working on). I've been working on the assumption of an aggregate description node with several child nodes with skeleton metadata for the objects in the gallery view.

@rangel35
Copy link

the way my module works, the book level has the metadata with each child "page" having a skeleton title, description (can be made optional), member of,

then each node gets a media file added, cover/page 1 for book level and each subsequent page gets its corresponding image...we chose not to ingest the large tifs due to space issues and only upload the png service files but the code can be adjusted easily to account for any type of media

incase an explanation helps your discussion :)

@dannylamb
Copy link
Contributor

Re-opening... my PR wording included the word resolved so this got auto-closed when @seth-shaw-unlv merged it. What got merged mostly satisfies this use case, but not quite.

@dannylamb dannylamb reopened this May 7, 2019
@seth-shaw-unlv
Copy link
Contributor

Related to this use-case, in case anyone is interested: I worked out a view based around the field_member_of w/ @dannylamb's help to display a node's children (both a block and an EVA) and a node's siblings (a block). They all use @dannylamb's slideshow image formatter. That siblings view was a pain to figure out, so I hope someone finds it helpful. I also have a hook_preprocess_views_view_list() implementation to add a 'active-sibling' CSS class to enable highlighting the row in the siblings block that matches the currently displayed node.

Some of the fields I display are UNLV specific but they can be easily removed/replaced. It wouldn't be difficult to turn this into something that works with islandora_demo as all the relationships are predicated on field_member_of.

@kstapelfeldt kstapelfeldt added Type: use case proposes a new feature or function for the software using user-first language. and removed use case labels Sep 25, 2021
@kstapelfeldt
Copy link
Member

@Natkeeran where do you think this use case is now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: use case proposes a new feature or function for the software using user-first language.
Projects
Development

No branches or pull requests

5 participants