bigbluehat / blueink Goto Github PK

Currently this thing's pretty tangled... 🍝

The doc.name === the type~{name} value. When really, doc.name should be the display name...or at least there should be a "pretty" display name stored somewhere.

Things to fix/refactor:

• _view/by_type
• _view/type_definitions
• _list/types_list (...which is currently busted and unused...)
• src/menu-content/*
• type loading in main.js (which uses _view/type_definitions to load component.js files.

Somewhat related to #18 as getting this right means meaningful content shared "everywhere." Doing it wrong will be...less good... 😩

Ran into some trouble with v-repeat over objects passed in with v-with...

Likely, there's a much better way to approach this anyhow as a stack of simpler Vue Models.

Keeping the full list of blog posts in a page area will mean the entire archive must be moved when a blog is dragged into a different column. It would be much better to only move the reference and store the blog posts in their own key.

Research using Bosonic for building out the new UI.

Use Sortable for new Drag & Drop UI.

Options:

• use an _update endpoint
• set from the UI code
• validate_doc_update (with either option)
  • prevents replication of non-valid docs...which is probably not what we want...actually

Dug into this a bit last night, but hit issues with doing npm install, etc from gulp.

Ideally, you'd gulp the site project, it would in turn handle building all the type~{name} documents (and/or grabbing them from npm), and push them all to the database along with BlueInk itself (and possibly the BlueInk "core" types--assuming you've not overridden them.

Consider outputting <audio> tags and making ID3 info available (if present in JSON)

shows/html/map.js contains the most generic content item templating so far. That's likely reusable (with some tweaks) for contact's and possibly many others.

Pages in sitemap _list output are alphabetical. They need to be ad-hoc order-able.

Alternate to #12 ...maybe:
https://github.com/desandro/draggabilly

Cool, regardless.

Third level to the right in the Content Menu. Requires #16 to be done first (obviously).

Based on the commercial/production BlueInk's UI, but all in HTML5 and CSS3:
http://demo.blueinkcms.com/

This MapReduce and associated _list function should be able to generate the 'sitemap' document. Initially it'll be requested and then stored (replacing the old 'sitemap') via the UI (on page add or URL change), but eventually it would be great to have this use view merging (once that's available).

There's a tricky balance between flexibility for designers/developers and consistent feature delivery (RDFa) among BlueInk sites. Try to balance that...simply.

Scope this thang!...as much as possible without scoped CSS...anyhow.

The bootstrap example page shows some collision.

Link each item to the _show function URL (or the _rewrite equivalent) for each item.