-
Notifications
You must be signed in to change notification settings - Fork 71
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
Make a "whole object" view #886
Comments
@dannylamb the UI that I was describing during yesterday's CLAW call used a tab, like the one that I've implemented in the 7.x Islandora Metadata Extras: Then, in that tab: But I reckon that implementing this as a View will allow us to do a whole lot of useful things with it. |
Dunno what the Views module actually does with JSON-LD, but the natural RDF idiom would be a straight merge of graphs or datasets.The tricky bit for JSON-LD might be in the contexts, but presumably, "collision avoidance" is on the repo managers? Inserting a more adjustable aggregation in there seems like a bit of a can of worms... |
@mjordan We can make it a tab whether its views or any other custom path we go down. We don't really have the manage tab anymore, though we'll hit the tipping point on # of tabs soon and will probably have to consider it or something like it. @ajs6f That's what a views REST export should do. Supposedly it will just spit out the jsonld for each entity listed in the view. But you never know™️ . It'll be neat to see what happens. |
@dannylamb good point about the Manage tab. |
@ajs6f I take it from the image that you prefer vertical Tabs as opposed to the horizontal variety? |
Personally, I like caffeine-free tabs with artificial sweeteners, because I am one of the beautiful people. |
At our last CLAW call we talked about alternatives to the "whole object view". One of the things that came up was using blocks instead of tabs, with access control/role determining what you can see. This would make the canonical node url the "whole object" view. Previously we avoided blocks because they're tied to a particular theme when you export them, which made the core islandora module require said theme. But now that we've got things separated out between our "core" and "demo" features we should be good on that. It'd certainly cut down on the # of tabs. |
I've made a crude start on this at https://github.com/mjordan/islandora_whole_object. Decided to use a tab for now but I'll tackle adding a block next. |
@mjordan I like the table output, it's almost like saying "give me all the triples". If you want to play around with blocks, export it out as part of Something to consider would be pulling in related entities and making those available when the template is rendered. I think pulling in all the associated media, members, and taxonomy terms in one place is really what's at the heart of this issue. I wonder if it's possible to render the results of a view from a twig template? If so, you could latch onto existing views pretty easily to paint a bigger picture. |
Sounds good. So far I've been using the Drupal theme layer to assemble the content in a very simplistic way. Would like to explore the view/Twig template approach for the cannonical representation. Just to be clear - are you referring to a capital 'V' View or something else? |
Lol, I'm talking Drupal Views, not Model-View-Controller. |
It would be nice to have a view that encapsulates and entire object (e.g. its descriptive metadata + members + media) in a single display. Looks like this can be done with the views_field_view module, but will require some exploration for sure.
It will be interesting to see what sort of jsonld gets generated by a REST export of the view, too. This could be a pattern for rendering arbitrary graphs in jsonld using a UI without needing a template.
The text was updated successfully, but these errors were encountered: