michaelquigley / capsule Goto Github PK

Implement Capsule.Type handling within the Model. Delegate to a strategy to identify the type.

Investigate fs.FS and building around that approach for filesystem encapsulation.

What can we learn from Deepdwn (https://billiam.itch.io/deepdwn)?

It looks like Deepdwn provides some interesting development and organizational features on top of Markdown, which makes working with groups of documents easier.

Need to consider those kinds of development tools and how they might work on top of capsule.

Rather than depending on the user to do the right thing with {{ define }} inside templates, write code to name templates automatically using the directory structure path names.

The TimelineIndex renderer currently looks for a hardcoded timeline structure. This should be configurable (through renderer.yaml) to allow for multiple timeline structures.

The same pattern will be useful for other renderers/builders.

It looks like a lot of the performance improvements brought by godirwalk have been fixed up in the standard fs.WalkDir (or at least enough of them have been). So we should be able to do away with that dependency.

Track all of the files that comprise the build, and then remove any files that don't belong.

This is better than just removing everything, so that we can do lazy file copies.

Implement a "visitor" concept in the static compiler, which can be used to produce instance data, which can be used in downstream renders.

Produce V["body"], V["short"], V["title"] or other elements that need to be computed from the persistent content, making it accessible for use in rendering.

Implement TimelineStructure.

Logically dump the Model structure for inspection and debugging.

Implement an idiomatic facility for dumping model.Model.Structures.

Migrate from .structure to structure.yaml; first-class feature.

Register builders and renderers globally. Get rid of the naked:

CfOptions().AddFlexibleSetter("timeline", func(v interface{}, opt *cf.Options) (interface{}, error) {
	return &TimelineStructureBuilder{}, nil
})

Surely there is something we can do with links between nodes, which is better than a raw path?

Implement a simple, extensible template for journal capsules.

Automatically take high-resolution source images and produce whatever types of derivative images might be necessary.

Can we extend our Markdown parser to allow us to reference figures from within the story?

Just a basic image link?

Develop a "strawman" capsule filesystem structure.

A first user interface spike for a development view of the capsule model.

A feature rendering spike for the static compiler.

Instead of generating a static.Node for use throughout the build, extend the model to support "intermediate" ("build") data.

With the structure model defined as a feature, use a structure.yaml feature to declare structure rendering contributions to the Story (Body) output on a node.

Expand the MIME-like "type" information into a more nuanced "class", "role", "type" structure.

Class being "image", "text", etc.

Role being "story", "hero", "cover".

Type being "markdown", "png", etc.

Check file sizes and modification timestamps and only copy if a difference is detected. Provide a switch to force copy.

Would be super handy to be able to enable debug logging on a per-"channel" basis.

We're going to want to copy the static resources (images, audio, videos, etc.) and at least include an attachments list in the output.

Replace the capsule.Node.FeaturesWith and capsule.Node.FeaturesWithout with a new capsule.Features type, with fluent methods like With, Without, Named, etc.

Can we implement a native SASS-like facility for CSS resources?

We're going to ultimately want to use a different template for certain nodes. We're going to need a "data" feature to contain this kind of stuff... but this data is really specific to the rendering of the capsule, not part of the capsule itself. This data ("configuration") should probably exist as overlay data in a the resources.

Implement structural directives.

Rather than having the static compiler intrinsically render each node to an index.html file, create a StoryRenderer and use the existing configuration/globbing infrastructure to use it.

Implement a server process, to take a rendered capsule and provide the service scaffolding around that render.

Could grow in the future to support subscriptions, mailing list signup, contact, etc.

Implement a basic skeleton for the static HTML transpiler.

Would be useful to have a model where capsule contents can work like a zettelkasten or a wiki. Inlinks and outlinks, tracked.

I really like when the output of a generator can be run through a "tidy" utility. Would love to get something working here.

Develop a "journal" example.

[email protected] - People keep asking "why no markdown support in #Lichen?" I've spent a great deal of time thinking about it.

Gemtext is truly better: it supports all the richness of a good book, and the ability to link or reference other information.

Hypertext inline links are just a gimmick, a technical trick that we've grown used to. How many times has the ability to "click here" made the written content better or deeper? Zero.

I challenge you to at least try writing without inline links. It's not hard.

Parallel to conversion from .structure -> structure.yaml, .capsule -> capsule.yaml.

A second attempt at a structural directive metaphor.

https://en.m.wikipedia.org/wiki/Monograph

https://brianlovin.com/writing/make-a-personal-changelog

Differentiate between different resource types. Templates should live in a specific sub-path. Static resources in a different sub-path.