search

CollectionBuilder / collectionbuilder-gh

A framework for creating digital exhibits from a folder of files and a spreadsheet. See Readme below for instructions to get started!
https://collectionbuilder.github.io/collectionbuilder-gh/
MIT License
93 stars 78 forks source link

Alt features #52

Closed dcnb closed 3 years ago

dcnb commented 3 years ago

This PR expands upon @evanwill updates from last night. The code is expanded and uses captures and specific references to account for use of multiple types and captions on same page.

Also adds clean up for youtube links and revises documentation to be more readable; adds multiple options for external images, as well as link option to link images out (this one might not be necessary but I can see a user wanting to use an image to link back to original page for image),

And, adds Includes Bonanaza page for testing and reference (/includes_options.html) -- we might move that one just to the demo page ...

evanwill commented 3 years ago

@dcnb I removed float option to simplify a bit more.

Does the "options_page.html" belong in "feature", or better in "cb" folder? Does it need to have pictures of me? Should it have comments at the top about what it is and how to use it? s

on the about_the_about trying to get working samples--it just seems highly likely to break, so if the idea is to get working, non broken examples, it seems best to just use external link for each instead. the demo code gives an example as if it was in your repo, but the rendered include is always external item (maybe from https://www.lib.uidaho.edu/collectionbuilder/dhsi-demo or maybe need to put demo items in stable location on collectionbuilder.github.io ). people will get the idea, it wont ever be broken.

evanwill commented 3 years ago

oh I didn't actually even notice the new "pages/include_options.md" page. If we keep that, I would just move the contents of the include into this stub, there isn't really a reason for it to be an include. Might be good to see the example code in Markdown rather than in an include.

Otherwise, delete the page, keep the include somewhere--so that you can add it anywhere for testing?

but I don't think both options

dcnb commented 3 years ago

Still need to remove your pic and work on about_the_about.

Got cloud working after long time having issues because I named the header above it "cloud" which then made the header:

Cloud

which messed up the javascript. maybe we should change the id it's referencing ...

evanwill commented 3 years ago

ha ha, yeah probably need some method to generate a probably unique id in case someone uses more than one.

evanwill commented 3 years ago

@dcnb i just added a bit to come up with a probably unique id for any cloud div. The whole arrangement doesn't exactly make sense any more--it is sort of historical gradual evolution why it is like it is... but right now, the reason you had to put the cloud div manually on the page was that it used to load the cloud-js in the foot--> now we just load it where ever you pull it in. So really this bit:

{% assign cloud_id = "cloud-div-" | append: fields | slugify %}
<div id="{{ cloud_id }}" class="text-center my-4 bg-light border rounded p-2"></div>

could just be moved into the "cloud-js.html" to avoid repeating it everywhere else. The only advantage I see to manually doing it is that you might want to customize the classes on the div to give different background etc, which i guess we could just add into the include options too. Then part two of that question is, should "js/cloud-js.html" just move everything into "feature/cloud.html" since at that point there isn't a real reason why you need the different set ups. The cloud layout does the weird calculations to support the theme.yml settings, but could use feature/cloud.html just the same as js/cloud-js.html. Or is there a possibility that they would diverge in look and feel?

dcnb commented 3 years ago

I added more cloud options. They are super cool. I think people will like them.

I kept cloud-js.html in the includes/js folder ---> I think since that piece of code gets hit from both the full page build and as a feature, it makes sense to leave it there, and pull options through the includes command. I did wonder about just pulling that <div ...> into the js although this way at least indicates that somethings being added to a page, and then more code is being pulled in, which might be helpful?

I also added an external_link option to the config-metadata. This has been repeatedly asked for, so I think we should just add it. We should add it to the other types too. IT was simple enough.